So I admit it's a 10 minute hack done on my way home on the train, but the issue is real even if you understand the man page. Here's roughly the way these work normally.
Starting with "login" bash invocation- which means:
* On linux, usually only when you first ssh into a machine or boot up into a terminal- and then _never again_ as you open various terminals or su etc. If you boot into gdm or something like most desktops/laptops do nowdays, you may hardly ever see your local machine invoke bash as a login shell.
* On a mac, "login" mode is invoked on pretty much every terminal you open.
* The login mode of a shell is _orthogonal_ to the shell being interactive (in theory. In practice, and in the gist, a login-shell is almost always a small subset of interactive shell invocations [or larger subset on mac]).
The rules for the login shell invocation are to load:
('/etc/profile' THEN (~/.bash_profile OR ~/.bash_login OR ~/.profile - one and only one, the first one it finds)) (and nothing else)
UNLESS bash is invoked as a login shell with the 'sh' name, in which case it does:
('/etc/profile' THEN ~/.profile)
IF the shell is NOT a login shell but IS interactive, don't load any of the profile stuff but load ~/.bashrc (ignored if bash is invoked as 'sh')
Finally, a shell in posix mode and a shell invoked by a script- i.e., non-interactive, will first load any file specified in the BASH_ENV environment variable and nothing else.
On a mac, the default for new home directories is to have a ~/.profile sitting there. Should you unwittingly drop a ~/.bash_profile or ~/.bash_login in there one day, you would find (and many have found) that the ~/.profile suddenly stops working (more likely you suddenly notice your PATH isn't set anymore). Except sometimes, when bash is being invoked as sh, in which case ~/.profile is alive again.
And, note that .bashrc isn't loaded at all for a login invocation, even if it is interactive (true the vast majority of the time). On a mac, .bashrc seems useless, then on linux, .bash_profile seems useless. So many on linux end up filling up their .bashrc with the good stuff and then realize that when they log in remotely nothing gets loaded so they troubleshoot, read the manpage, and end up sourcing .bash_profile from their .bashrc. On mac, people tend to do the reverse. Oh, and when you are trying to remember what is what and why you should care-- the manpage is almost 5,000 lines long. AFAIK, it's the only manpage the size of a book.
Anyway, I was putting my dotfiles into github and spend a lot of time on OSX and Linux so was merging the two sets. I also have seen (and written) so many rc scripts that liberally mix stuff that is relevant for interactive-mode with stuff that should really only be done at login, etc. That said, it _is_ a 10 minute hack so forks + fixes appreciated.
Could you achieve the same outcome by spreading the logic though the three standard bash dotfiles? Standard names plus no symlinks, i could live with that.
Kind of... That's pretty much what mine had evolved into, a bunch of them sourcing each other and making sure they weren't recursively sourced for when they're used on a different OS/machine, with complex conditionals to re-detect if it was interactive or not and logic to try to not re-run things too often that was only supposed to be run on login... with no certainty that they were really doing what I intended in weird circumstances like `ssh ... command`.
But those wouldn't have been "shareable" or standard either- unless they were all shared as a group. When someone says "here are some lines from my .bash_profile"- they are not implying something by having them in bash_profile and not bashrc. No one in their right mind would think "must be something they only want to run when they log in." Instead, you take those lines and put them into your .bashrc or .profile or whatever you happen to have working well enough. Or, worse, someone says "here's my .bash_profile" and someone new to osx drops it in their home directory and all of a sudden nothing works because bash stopped looking at their .profile that already existed, while someone on linux drops it into their home directory and it looks like it's not doing anything at all.
etc. (: obviously people get it to work, and obviously "madness" was a euphemism, but I was tired of all the ambiguity.
You could also replace each of the dotfiles with a script to source the dispatcher. No redundant logic, and you don't mess with system files in a way that might screw up install scripts, etc. (But unless I'm missing something it doesn't seem like you'd break that much by using symlinks.)
Starting with "login" bash invocation- which means:
* On linux, usually only when you first ssh into a machine or boot up into a terminal- and then _never again_ as you open various terminals or su etc. If you boot into gdm or something like most desktops/laptops do nowdays, you may hardly ever see your local machine invoke bash as a login shell.
* On a mac, "login" mode is invoked on pretty much every terminal you open.
* The login mode of a shell is _orthogonal_ to the shell being interactive (in theory. In practice, and in the gist, a login-shell is almost always a small subset of interactive shell invocations [or larger subset on mac]).
The rules for the login shell invocation are to load:
('/etc/profile' THEN (~/.bash_profile OR ~/.bash_login OR ~/.profile - one and only one, the first one it finds)) (and nothing else)
UNLESS bash is invoked as a login shell with the 'sh' name, in which case it does:
('/etc/profile' THEN ~/.profile)
IF the shell is NOT a login shell but IS interactive, don't load any of the profile stuff but load ~/.bashrc (ignored if bash is invoked as 'sh')
Finally, a shell in posix mode and a shell invoked by a script- i.e., non-interactive, will first load any file specified in the BASH_ENV environment variable and nothing else.
On a mac, the default for new home directories is to have a ~/.profile sitting there. Should you unwittingly drop a ~/.bash_profile or ~/.bash_login in there one day, you would find (and many have found) that the ~/.profile suddenly stops working (more likely you suddenly notice your PATH isn't set anymore). Except sometimes, when bash is being invoked as sh, in which case ~/.profile is alive again.
And, note that .bashrc isn't loaded at all for a login invocation, even if it is interactive (true the vast majority of the time). On a mac, .bashrc seems useless, then on linux, .bash_profile seems useless. So many on linux end up filling up their .bashrc with the good stuff and then realize that when they log in remotely nothing gets loaded so they troubleshoot, read the manpage, and end up sourcing .bash_profile from their .bashrc. On mac, people tend to do the reverse. Oh, and when you are trying to remember what is what and why you should care-- the manpage is almost 5,000 lines long. AFAIK, it's the only manpage the size of a book.
Anyway, I was putting my dotfiles into github and spend a lot of time on OSX and Linux so was merging the two sets. I also have seen (and written) so many rc scripts that liberally mix stuff that is relevant for interactive-mode with stuff that should really only be done at login, etc. That said, it _is_ a 10 minute hack so forks + fixes appreciated.