(Source: ofek/userpath wrong shell #3)
Rant mode ON. 🙀
Just FYI (Unix geek here), I think bash is broken by design when it comes to startup files. This is especially true in big university multiuser Unix installations, which is my own background. For proof, run man bash, look under the "INVOCATION" section, and prepare to have your mind blown. Compare and contrast this with man zsh and look under "STARTUP/SHUTDOWN FILES", for a much less insane approach to system and user configuration. IMHO. 👀
Red Hat Enterprise Linux, Ubuntu, and probably other OSes or distros attempt to work around the bash problem by providing clever dotfiles in "/etc/skel" -- these are dotfiles that are copied into a new user's home directories by default when the new user is created. These default dotfiles are supposed to create a complex structure where each user has a ~/.bash_profile (OR ~/.profile on Ubuntu) which always sources the user's ~/.bashrc. That way, both dotfiles will be executed for login shells, and the bulk of the configuration can be put into ~/.bashrc. On Red Hat, ~/.bashrc IN TURN also sources /etc/bashrc. To repeat; ~/.bash_profile sources ~/.bashrc sources /etc/bashrc. You could say that on Red Hat, Ubuntu et. al. it would be considered broken behavior NOT to create these default dotfiles in a new user's home directory.
Take a wild guess if Apple creates bash dotfiles in users' home directories on macOS? Of course not. 🤦 Instead, as @AlJohri noted above, they just run every Terminal window as a login shell (!). 🤦
I'm just happy Apple finally decided to switch from bash to zsh starting with macOS 10.15 Catalina, so the problem with bash will eventually go away there.
Rant mode OFF. 😉
I believe the best way to treat bash users is probably to assume that the user will encounter at least one "login shell" somewhere during the login process before running userpath, and add our PATH definition to the first dotfile for bash login shells that we find. The reason I say this is that these files are also where Red Hat, Ubuntu and others suggest that users should add their own $PATH definitions. To quote from the manual, a bash login shell:
looks for
~/.bash_profile,~/.bash_login, and~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
Note — ONLY from the first one. If a ~/.bash_profile exists, that will disable the other two files, as far as bash is concerned.
What to do if none of the login dotfiles exist? That's a trickier question.
- The safest behavior is to exit with an informative error message.
- You could also look for a ~/.bashrc file, and hope that the user or the OS has some arrangement for running it most of the time. But this is NOT guaranteed to work — especially for "login shells", since they don't read ~/.bashrc. On macOS, every Terminal window is a login shell... So that does not work. 👀
- On macOS, which is known to be "broken" for bash users (i.e. no user dotfiles exist by default), I might consider creating an empty ~/.bash_profile if none of the other login shell dotfiles exist, and THEN adding any additional PATH definitions to our newly created ~/.bash_profile.
- Starting with macOS 10.15 Catalina, all bash users are told (in their Terminal windows) to switch to zsh, and new users have zsh by default. So this problem will decrease over time.
To sum up... This is my opinion, but I'm basing it on a lot of experience with Unix shell scripting and user support at university Unix systems. I don't believe that there's a single "correct" solution for bash. But we can try to be as helpful as possible, at least.
I'll be happy to answer any additional questions about this subject. 😄