Bash Configurations Demystified | Hacker News Reader

Bash Configurations Demystified

dghubble.com

106 pointsdghubble20 comments

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

^ broken link.

http://blog.flowblok.id.au/2013-02/shell-startup-scripts.htm...

Edit: Not that I recommend the resource, just fixed the link for you.

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

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.

The point of a separate login shell script is so you can have login banners telling you useful information about the system when you're initially logging in, but not when you just do something like run bash or su.

In ubuntu that's stuff like the load average of the machine or whether or not there are packages that need to be upgraded.

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.

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

~/.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.

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

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

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.

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

Ubuntu uses .profile when you login via gdm (i.e., graphically).

     > 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

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.

I think many Linux users have hacked around and messed up settings. This line was meant for those who have been in that situation, to say "hey btw, that screen was a login shell" (even took a picture of it). Just adds a little context, it doesn't resonate with everyone.

I think booting to a console when you expect a desktop can be scary, especially if you don't know how to undo whatever you did.

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?

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

This is really helpful, thanks.

Reply on news.ycombinator.com