
Bash Configurations Demystified - dghubble
http://dghubble.com/.bashprofile-.profile-and-.bashrc-conventions.html
======
gue5t
See <[http://blog.flowblok.id.au/2013-02/shell-startup-
scripts.htm...](http://blog.flowblok.id.au/2013-02/shell-startup-
scripts.html>), the most comprehensive overview I've encountered to date.

~~~
dghubble
^ broken link.

~~~
Pwnguinz
It has to do with the fact that the GP put the URL in < > and HN assumed the
trailing > was part of the URL. Just remove the trailing > in the URL and
it'll work.

Alternatively reproduced here without the '>':
[http://blog.flowblok.id.au/2013-02/shell-startup-
scripts.htm...](http://blog.flowblok.id.au/2013-02/shell-startup-scripts.html)

------
deathanatos
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.

~~~
ChuckMcM
Because when you run a script in a shell you don't want the script printing
out the message of the day and messing with things. Say for example you want
to create a new shell with LD_LIBRARY_PATH and PATH that are different than
you set them when you login. If you always start a login shell your .profile
is always run and you always reset your paths.

------
eslaught
> 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.

~~~
dghubble
~/.profile is executed only at login on Ubuntu so changing your PATH there
will be applied the next time you login. You can source the ~/.profile in your
current non-login shell if you need the PATH change right now. I've tried to
tweak the second paragraph in the "When not to modify .bashrc?" section to
make this more clear.

Thanks for bringing this up.

~~~
eslaught
The problem is that running an MPI program on a remote node starts a new non-
interactive SSH session. That SSH session has no parent login session, so it
won't inherit environment variables from any session that read the .profile
file. And because the SSH login is non-interactive, the only file that the
shell inside the SSH session reads is .bashrc.

Sure, you could source .profile manually, but this is awkward to code inside
an MPI application. In addition, this will cause .bashrc to get sourced twice,
because your shell already read .bashrc when it started the SSH session.
Hopefully your .bashrc is idempotent, but even so, it feels wrong to have to
read .bashrc twice.

Try this on a remote server:

    
    
        remote:~$ cat .profile
        echo "read .profile"
    
        echo "sourcing .bashrc from .profile"
        source ~/.bashrc
        remote:~$ cat .bashrc
        echo "read .bashrc"
    

And then from your local machine:

    
    
        local:~$ ssh remote
        read .profile
        sourcing .bashrc from .profile
        read .bashrc
        local:~$ ssh remote -k true
        read .bashrc

------
johnbellone
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...](https://github.com/johnbellone/dotfiles/blob/master/home/.bash_profile)

My .bashrc
[https://github.com/johnbellone/dotfiles/blob/master/home/.ba...](https://github.com/johnbellone/dotfiles/blob/master/home/.bashrc)

------
m_ram
_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.

~~~
claudius
.profile works nicer if you run another Shell, I presume, so can be added to
_every_ users home directory upon creation and not just to those of Bash
users.

What I don’t get is why RVM adds a .bash_profile, when there is, for example,
/etc/profile.d/.

------
D9u

         > 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

~~~
pbhjpbhj
If you're only using a console because you broke your WM config (or something
similar) then I imagine it's quite intimidating.

"help" is the most likely first place looked for assistance in such
circumstances I'd imagine.

------
dbbolton
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?

~~~
lmz
Other shells (e.g. ksh) may only use .profile.

------
smewpy
This is really helpful, thanks.

