from Hacker News

Bash Configurations Demystified

by dghubble on 7/21/13, 4:28 AM with 20 comments

  • by gue5t on 7/21/13, 5:38 AM

    See <http://blog.flowblok.id.au/2013-02/shell-startup-scripts.htm..., the most comprehensive overview I've encountered to date.

  • by deathanatos on 7/21/13, 5:53 AM

    What's the reason for all the files, and why do I care whether my shell is a login or non-login? To me, no matter where I get my shell from (whether VT, SSH, gnome-terminal), I want all my aliases, settings and nice terminal colors to be there.

  • by eslaught on 7/21/13, 3:35 PM

    > As the name implies, .bashrc is for bash configs. Environment variables or other configuration settings should typically be written to .profile on Ubuntu and .bash_profile on OS X.

    I don't understand this. If I set PATH in .profile or .bash_profile, then on Ubuntu I won't see that setting when I log in via a non-login shell. This is common for non-interactive SSH sessions.

    So consider the following example:

      * I install MPI to /usr/local/openmpi-X.Y.Z
  * I add /usr/local/openmpi-X.Y.Z/bin to PATH, inside my .profile
    Now MPI is broken, because MPI executes out of a non-login shell when running on remote nodes via SSH.

    I think I'll keep my PATH settings in .bashrc, thank you very much.

  • by johnbellone on 7/21/13, 3:04 PM

    Excellent article.

    I recently had the task of straightening out the default install of dotfiles we had at my job. Since we're behind a corporate firewall and require various HTTP proxies to hit the outside world I devised pretty much the same setup as explained in the article.

    All of the environment exports are placed in .profile as, at the very least, I expect this to be sourced on a login shell. If there is a non-login shell, for the most part, most people tend to source it pretty early on in the process. The .bash_profile is kept around for diagnostic information for interactive shells such as the Ruby, Go, Node and Java versions of the machine you are logging into.

    Because everyone tends to have their own dotfiles I hijacked the .bash_login to keep machine specific information which can be optionally sourced. This leads me to tell people to basically keep .profile and .bash_login out of their revision control and to source both of them relatively early on in the login process.

    All .profile is for environment variables that are machine/network specific. If you have any overrides, e.g. aliases, all that goes into your .bash_login.

    My .bash_profile: https://github.com/johnbellone/dotfiles/blob/master/home/.ba...

    My .bashrc https://github.com/johnbellone/dotfiles/blob/master/home/.ba...

  • by m_ram on 7/21/13, 6:41 AM

    Programs like RVM add a .bash_profile file so you should be sure to append [[ -s ${HOME}/.profile ]] && source ${HOME}/.profile to the added .bash_profile file.

    You can also rename .profile to .bash_profile on Ubuntu and Debian. All other distros that I've encountered set up .bash_profile by default.

  • by D9u on 7/21/13, 11:22 AM

         > the scary console login after you've messed up your GUI settings
    That's where I stopped reading...

    BASH isn't that mysterious.

         man bash

  • by dbbolton on 7/21/13, 9:06 AM

    Is there a specific reason why you would want to source .profile from within .bash_profile instead of just making one a symlink to the other?

  • by smewpy on 7/21/13, 6:48 AM

    This is really helpful, thanks.