15
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.
2
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 bash
. Emacs eshell
is not bash
. Assuming that eshell
would load .bashrc
is as faulty as assuming zsh
or csh
would load .bashrc
. It's a different shell.
I see two options:
bash
and elisp code for eshell
.You might also be interested in the discussion on adding a directory to a path without duplicates.
1
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.
Some applications invoke interactive non-login shells, which means .profile and .bash_profile aren't read. If you want to set env vars for those applications, one way to do it is to set them in .bashrc even though that's not supposed to be the place for it; see https://github.com/mobile-shell/mosh/issues/102#issuecomment-12503646
– William – 2018-10-05T20:45:05.473@William
.profile
is read when you log in. Putting environment variables in.bashrc
doesn't work, and your scenario illustrates that: the (presumably GUI) application that runs this shell should have your environment variables, but if you define them in.bashrc
, it doesn't. – Gilles 'SO- stop being evil' – 2018-10-06T22:05:18.837mosh isn't a GUI, it's an alternative to ssh. I'm not defending its behavior, just trying to help others who encounter the same problem I and others have had, as described in the Github issue I linked. – William – 2018-10-08T18:12:11.280