See <<a href="http://blog.flowblok.id.au/2013-02/shell-startup-scripts.html>" rel="nofollow">http://blog.flowblok.id.au/2013-02/shell-startup-scripts.htm...</a>, the most comprehensive overview I've encountered to date.
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.
> 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.<p>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.<p>So consider the following example:<p><pre><code> * I install MPI to /usr/local/openmpi-X.Y.Z
* I add /usr/local/openmpi-X.Y.Z/bin to PATH, inside my .profile
</code></pre>
Now MPI is broken, because MPI executes out of a non-login shell when running on remote nodes via SSH.<p>I think I'll keep my PATH settings in .bashrc, thank you very much.
Excellent article.<p>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.<p>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.<p>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.<p>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.<p>My .bash_profile:
<a href="https://github.com/johnbellone/dotfiles/blob/master/home/.bash_profile" rel="nofollow">https://github.com/johnbellone/dotfiles/blob/master/home/.ba...</a><p>My .bashrc
<a href="https://github.com/johnbellone/dotfiles/blob/master/home/.bashrc" rel="nofollow">https://github.com/johnbellone/dotfiles/blob/master/home/.ba...</a>
<i>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.</i><p>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.
<p><pre><code> > the scary console login after you've messed up your GUI settings
</code></pre>
That's where I stopped reading...<p>BASH isn't <i>that</i> mysterious.<p><pre><code> man bash</code></pre>