Why .profile, .bash_profile, and .bash_login?

Configuring the startup of bash can seem to be an unnecessarily complex process with a plethora of configuration files all being read or ignored according to a mystifying set of rules.  The Invocation section of bash man page describes these rules in some detail but gives very few clues as to the reasons for their existence and the problems they were intended to solve. It is common for a change to one of the configuration files either to have no effect at all (ie: to be ignored), or to have unintended side-effects in another type of start-up.  Indeed, a search of Linux and Unix forums will reveal many threads dealing with of this type of problem.

This post is part of an attempt by me to understand the complexities of bash startup and to draw up some rules to simplify the use of the configuration files.  This attempt was inspired by installing RVM, the Ruby Version Manager which screwed up my Bash settings by creating a .bash_login file.  And this particular post was inspired by reading the following two paragraphs from Learning the bash Shell, 2nd Edition, Cameron Newham and Bill Rosenblatt, O'Reilly, 1998, page 59:

bash allows two synonyms for .bash_profile: .bash_login, derived from the C shell's file named .login, and .profile, derived from the Bourne shell and Korn shell files named .profile. Only one of these three is read when you log in. If .bash_profile doesn't exist in your home directory, then bash will look for .bash_login. If that doesn't exist it will look for .profile.

One advantage of bash's ability to look for either synonym is that you can retain your .profile if you have been using the Bourne shell. If you need to add bash-specific commands, you can put them in .bash_profile followed by the command source .profile. When you log in, all the bash-specific commands will be executed and bash will source .profile, executing the remaining commands. If you decide to switch to using the Bourne shell you don't have to modify your existing files. A similar approach was intended for .bash_login and the C shell .login, but due to differences in the basic syntax of the shells, this is not a good idea.

From these paragraphs I draw the following conclusions:

• .bash_login was introduced as part of an unsuccessful attempt at compatibility with the C shell.  This suggests that its use can be and should be avoided.  You should never create a .bash_login and if you have one you should not allow it to be activated (creating a .bash_profile should ensure this) and should delete it.
• .bash_profile is the appropriate place to put bash-specific commands to be run when starting a login shell.  It would seem sensible to always have a .bash_profile file and to never allow bash to read .profile directly.  Instead the .bash_profile should always end with a command to include the .profile, but rather than just source .profile it would be better to test .profile exists first, for example:

  if [ -f "$HOME/.profile" ]; then
    source "$HOME/.profile"
  fi
  

  Always having a .bash_profile has the additional benefit of preventing any .bash_login from running. 

The problems of what bash-specific commands are appropriate to a login shell and, indeed, what a login shell is and how it differs from a non-login shell, I will leave for another post.

Update on Fri 2012-07-20 by Tristram Brelstaff

In Ubuntu 12.04 ( and presumably also Debian 6 and other Debian-derived systems) the .profile attempts to load .bashrc if bash is running.  This rather breaks the rule that all bash-specific commands should go in .bash_profile.  If in your .bash_profile you load .bashrc and then load .profile, you will be loading .bashrc twice, which is undesirable.