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.

2 Answers 2


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:


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.

  • 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, 2013 at 23:36
  • My hurt brains more now. So much to learn, so little time. I'd +1 you but, you know, stackexchange :( Sep 18, 2013 at 10:48

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.

  • That works thanks. Now I just have to work out what it all means ! Darn you to Heck Windows(TM), you killed my brain ! Sep 13, 2013 at 14:33
  • Thx. I'm dying to know what could have possibly earned me a "-1" here...sigh.
    – goldilocks
    Sep 14, 2013 at 11:47
  • 1
    Are the 3 Bears on here ? I'll up vote you once I get my reputation up to 15 :) Sep 16, 2013 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. Sep 16, 2013 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, 2013 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.