12

As I asked and got answers in here, and here, the PATH variable has different path names depending on how the app is activated.

  • Which setup files (.bashrc, .profile, ...) should be used to have the same PATH variable no matter how I start the software with bash?

3 Answers 3

18

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.

3
  • 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 github.com/mobile-shell/mosh/issues/102#issuecomment-12503646
    – William
    Oct 5, 2018 at 20:45
  • @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. Oct 6, 2018 at 22:05
  • mosh 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
    Oct 8, 2018 at 18:12
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:

  1. Create your own script which takes a list of directories and generates the appropriate bash code for bash and elisp code for eshell.
  2. 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.

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .