[jjnoakes]

An article like this would be better if it didn't gloss over the different bash startup files and when they get loaded.

Many times when I help someone debug their shell, the root cause is not understanding what each of those files is for.

Adding an echo to the wrong one and not having it check if the shell is interactive can break all sorts of things like scp for example. And in weird and non-obvious ways.

[o11c]

It's outright wrong since it forgets ~/.bash_login

The startup files are mostly comprehensible if you understand the following two oddities:

* Some pseudo-terminal programs always start the shell as interactive; other pseudo-terminal programs always start the shell as non-interactive.

* Shells started from SSH are different than all other shells, regardless of interactivity.

* Shells other than bash are broken-by-design and really should not be used if you have any choice, but in the real world you do have to know at least a little about how to deal with their brokenness.

I have a much saner script here: https://gist.github.com/o11c/03a4b321220395b97dadc3f1ca740db...

[SoftTalker]

The shell man pages don’t really help either. They use terms like “login shell” and “interactive shell” without really defining or differentiating them.

[o11c]

They're defined, it just doesn't go into the weird details. From the man page:

       A  login shell is one whose first character of argument zero is a -, or
       one started with the --login option.

(not mentioned: the login(1) program does the dash thing when you log into a VT (as opposed to graphically, which has a whole nother complicated dance); login(1) is traditionally spawned by getty(8) which is in turn spawned by init(8). Some terminal emulators aggressively spawn login sessions; this is wrong but a common workaround for people who failed to configure their shell correctly, or who aren't using bash and thus don't have all the configurability)

       An interactive shell is one started without non-option  arguments  (un‐
       less  -s  is specified) and without the -c option, whose standard input
       and error are both connected to terminals (as determined by isatty(3)),
       or  one  started  with  the -i option.  PS1 is set and $- includes i if
       bash is interactive, allowing a shell script or a startup file to  test
       this state.

(or in other words: an interactive shell is one that outputs a prompt and waits for you to input something, as opposed to shells that are used to execute a file/pipe/string)

Further down, and often forgotten:

       Bash attempts to determine when it is being run with its standard input
       connected  to  a network connection, as when executed by the historical
       remote shell daemon, usually rshd, or the secure shell daemon sshd.

(this goes on to explain how .bashrc is loaded even when it normally wouldn't be)

These are orthogonal, and can be combined in various ways (there are also a few other possibilities mentioned in this part of the man page, but they're much less relevant):

Login shells are normally interactive, whether started sanely by login(1) or by unreasonable terminals.

Non-interactive login shells are rare and weird and sometimes declared "unsupported" by config-file authors, but do work if you're careful (a common error is to do a pseudo-motd in /etc/profile, which will break for non-interactive logins if you don't explicitly check for them; these days, a lot of things should really be done by PAM instead for better reliability).

Interactive non-login shells are what you normally create unless your terminal is dumb, or what you always create if you start bash within bash.

Non-interactive non-login shells are what scripts use.

The SSH special logic is ignored for the common case where you're doing an interactive login shell. But if you are doing a non-interactive non-login shell, it gives you chance to fix your PATHs, since no other startup files have been read. I think those are the only two possibilities with a normal SSH configuration (and in unusual configurations you are probably being restrictive); other shells would be created as a child of the initial shell. (Remember that SSH feeds its arguments to the shell directly; it does not quote them sanely!)