- Which setup files (.bashrc, .profile, ...) should be used to have the same PATH variable no matter how I start the software with bash?
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
~/.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.
The definitive answer is in the bash man page section on Bash Startup Files. "When an interactive shell that is not a login shell is started, Bash reads and executes commands from ~/.bashrc, if that file exists. "
Answers your other questions point out that eshell doesn't actually run
eshell is not
bash. Assuming that
eshell would load
.bashrc is as faulty as assuming
csh would load
.bashrc. It's a different shell.
I see two options:
- Create your own script which takes a list of directories and generates the appropriate bash code for
bashand elisp code for
- Set your ESHELL or SHELL environment variable so that you actually do run bash within emacs. That's what I do. Bash works fine in emacs.
You might also be interested in the discussion on adding a directory to a path without duplicates.
Setting your PATH in your ~/.profile should just work. That file is read upon login by every POSIX-compliant or Bourne-like shell I know of including bash. If you make changes to that file, you will have to log out and log back in for the changes to take effect. Since PATH is part of your login process's environment, it should be exported to every shell you start subsequently.