Traditionally, the place to define per-user environment variables on unix systems is ~/.profile
. This file is read by the login shell (i.e. the program that is started when you log in, and that you can type commands into), provided that the login shell is a Bourne-compatible shell.
Bash is a Bourne-compatible shell. When it is invoked as a login shell reads ~/.bash_profile
if this file exists, and ~/.profile
if ~/.bash_profile
doesn't exist.
As a rule of thumb, if you type your password in text mode (e.g., on a text console, or remotely with ssh), then the shell you get is a login shell.
However, if you type your password in a graphical program and get logged into a graphical environment, this bypasses the normal login shell. Whether .profile
is read in this case depends on how the graphical session is set up; for instance it varies between Linux distributions, between display managers and between desktop environments. Sometimes one of the programs in the chain explicitly invokes a login shell; sometimes one of the programs explicitly reads ~/.profile
; and sometimes none of this happens and ~/.profile
doesn't get read.
To give an example of the variability, as far as I can tell from a quick glance at the scripts involved, on Ubuntu 10.04: if you log in with kdm or lxdm, ~/.bash_profile
is read if it exists, and ~/.profile
otherwise; if you log in with gdm, only ~/.profile
is read; if you log in with xdm, ~/.profile
is not read.
All the systems I know provide some way of setting per-user environment variables. Unfortunately there is no general answer.
Note that sometimes you'll see recommendations to either set environment variables in ~/.bashrc
, or start a login shell in each terminal in a GUI environment. Both are bad ideas; one of the reasons is the problem you've experienced, namely that your environment variables were only available in programs started via a terminal, and not in programs started directly with an icon or menu or keyboard shortcut.