4

I have a bin directory in home/pi. This is added to my $PATH when I login (by .profile), but when I go into LXDE and use LXTerminal my bin directory is no longer added to $PATH.

Funky Oordvork
  • 55

2 Answers2

3

On most setups, ~/.profile is read at login time and this is the usual place to set environment variables. Unfortunately some combinations of distribution, display manager (graphical login method) and desktop environment skip that file. You don't specify which display manager you're using (lxdm?), but it apparently doesn't arrange to read ~/.profile when the X session starts.

I believe that Raspbian supports ~/.pam_environment. This file is read by every login method which includes a not-to-antique pam_env in the PAM auth or session section. I believe that is the case on Raspbian (check that /etc/pam.d/common-session or /etc/pam.d/lxdm contains a line mentioning pam_env.so). You can define environment variables in ~/.pam_environment, but the possibilities are more limited than in ~/.profile: you can only write VARIABLE=VALUE, you can't use other variables or add to the existing value of the variable. So you can't write PATH=$HOME/bin:$PATH like you would in ~/.profile, you have to spell it out:

PATH=/home/pi/bin:/usr/local/bin:/usr/bin:/bin

I don't recommend setting environment variables in .bashrc. This would override the existing values whenever you start a subshell, and the variables would only be defined in programs started via a shell in a terminal and not in programs started directly from the GUI.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • I think the fact that you can't add to the existing $PATH (as defined for the system) makes this method infeasible or undesirable for many users, but it is good to know about. +1 – goldilocks Sep 16 '13 at 23:36
  • My hurt brains more now. So much to learn, so little time. I'd +1 you but, you know, stackexchange :( – Funky Oordvork Sep 18 '13 at 10:48
0

From man bash:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When a login shell exits, bash reads and executes commands from the files ~/.bash_logout and /etc/bash.bash_logout, if the files exists.

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists.

"Interactive shells" are ones starting in the foreground on a terminal, but they are not necessarily login shells.

A login shell is one whose first character of argument zero is a -, or one started with the --login option.

GUI terminals don't do that.

This is why generally, .profile sources .bashrc -- then .bashrc can contain the stuff you want for all shells, and .profile any additional stuff just for login shells. Sometimes this is qualified in .profile by checking if $PS1 (the interactive prompt) is defined, so that .bashrc only gets included for interactive ones. One reason for this would be to avoid the use of certain aliases in non-interactive (e.g., script execution) shells.

So: you could put your $PATH definition in ~/.bashrc, and make sure it is sourced from ~/.profile or ~/bash_profile.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
  • That works thanks. Now I just have to work out what it all means ! Darn you to Heck Windows(TM), you killed my brain ! – Funky Oordvork Sep 13 '13 at 14:33
  • Thx. I'm dying to know what could have possibly earned me a "-1" here...sigh. – goldilocks Sep 14 '13 at 11:47
  • 1
    Are the 3 Bears on here ? I'll up vote you once I get my reputation up to 15 :) – Funky Oordvork Sep 16 '13 at 12:17
  • Please do not recommend setting environment variables in .bashrc. It only half works and causes trouble down the line. See my answer. – Gilles 'SO- stop being evil' Sep 16 '13 at 23:24
  • @Gilles If the "trouble" is that it's not used by non-interactive shells, I did spell this out and suggest sourcing it from ~/.profile (which many systems do by default). WRT to overriding existing env values in a subshell, isn't that the point (as opposed to an undesirable side effect)? – goldilocks Sep 16 '13 at 23:52
  • @goldilocks The most common problem is that applications started from the GUI don't have the environment variable defined. Another problem is when .profile runs programs that should be executed once per session (e.g. keyring). Overriding the environment in a subshell is almost always undesirable: if the environment isn't the one that the session started with, there's usually a good reason (and if you want a shell with your default environment, su - $USER or ssh localhost can do that). – Gilles 'SO- stop being evil' Sep 17 '13 at 00:11