Home / ubuntu / Questions / 432508
Accepted
terdon
Asked: 2014-03-11 17:23:08 +0800 CST

Why does Ubuntu's default ~/.profile source ~/.bashrc?

  • 772

These are the contents of the stock ~/.profile that came with my 13.10 (commented lines removed):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

This is inherited from Debian but why did Canonical decide to keep it? As far as I know, it's not the standard *nix way and I have seen various systems where this did not happen, so I assume they must have had a good reason to. This can cause unexpected behavior when running login shells (such as when sshing into the machine for example) where the user would not expect to have ~/.bashrc sourced.

The only benefit I can think of is to not confuse the user with many startup files and allow them to edit .bashrc alone and have that read irrespective of shell type. That, however, is a dubious benefit since it is often useful to have different settings for login and for interactive shells and this blocks you from doing so. Also, login shells are very often not run in a graphical environment and that can cause errors and warnings and problems (oh my!) depending on what you've set in those files.

So why does Ubuntu do this, what am I missing?

bash

2 Answers

  1. Best Answer

    This is an upstream decision coming from Debian. The rationale for it is explained in this very nice wiki post, of which the following is an excerpt. The executive summary is "to ensure that GUI and non GUI logins work in the same way":

    Let's take xdm as an example. pierre comes back from vacation one day and discovers that his system administrator has installed xdm on the Debian system. He logs in just fine, and xdm reads his .xsession file and runs fluxbox. Everything seems to be OK until he gets an error message in the wrong locale! Since he overrides the LANG variable in his .bash_profile, and since xdm never reads .bash_profile, his LANG variable is now set to en_US instead of fr_CA.

    Now, the naive solution to this problem is that instead of launching "xterm", he could configure his window manager to launch "xterm -ls". This flag tells xterm that instead of launching a normal shell, it should launch a login shell. Under this setup, xterm spawns /bin/bash but it puts "-/bin/bash" (or maybe "-bash") in the argument vector, so bash acts like a login shell. This means that every time he opens up a new xterm, it will read /etc/profile and .bash_profile (built-in bash behavior), and then .bashrc (because .bash_profile says to do that). This may seem to work fine at first -- his dot files aren't heavy, so he doesn't even notice the delay -- but there's a more subtle problem. He also launches a web browser directly from his fluxbox menu, and the web browser inherits the LANG variable from fluxbox, which is now set to the wrong locale. So while his xterms may be fine, and anything launched from his xterms may be fine, his web browser is still giving him pages in the wrong locale.

    So, what's the best solution to this problem? There really isn't a universal one. A better approach is to modify the .xsession file to look something like this:

    [ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

    This causes the shell that's interpreting the .xsession script to read in /etc/profile and .bash_profile if they exist and are readable, before running xmodmap or xterm or "execing" the window manager. However, there's one potential drawback to this approach: under xdm, the shell that reads .xsession runs without a controlling terminal. If either /etc/profile or .bash_profile uses any commands that assume the presence of a terminal (such as "fortune" or "stty"), those commands may fail. This is the primary reason why xdm doesn't read those files by default. If you're going to use this approach, you must make sure that all of the commands in your "dot files" are safe to run when there's no terminal.

    • 16

  2. This is Ubuntu's standard behaviour, ~/.bashrc is user-level per-interactive-shell start up file. When you open a terminal basically you start a non-login, interactive shell which reads ~/.bashrc and contents of ~/.bashrc get sourced and exported into your current shell environment. It helps one to obtain all his user defined shell variables and functions in the current shell. Also you could find lines like this 

    if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

    to obtain user defined aliases in current shell environment.

    This is important in order to provide good user experience also. For example one could store proxy credential in .bashrc, unless it get sourced none of terminal applications (viz, ping, wget, curl, lynx etc.) will work properly. Or you have to provide the proxy credentials every time you open a terminal.

    Besides Ubuntu's default .bashrc contains many user friendly aliases (for ls and grep to print colourized output), many new definitions for different shell variables which increases user experience.

    But in case of your ssh login, or login in virtual console, you basically get an interactive login shell. There the shell initiation file is ~/.profile. Hence unless you source ~/.bashrc you miss all those helpful settings in your .bashrc. That is why Ubuntu's default ~/.profile source ~/.bashrc

    Case to avoid

    • you should never source ~/.profile form inside ~/.bashrc at the same time when ~/.bashrc is being sourced from ~/.profile. It will create an infinite loop of situation and as a result your terminal prompt will be suspended unless you hit Ctrl+C. In such a situation if you put a line in your ~/.bashrc
    set -x

    Then you could see that the file descriptor is stopping when you open a terminal.

    • 3