Any occasion where .bashrc is favorable to .bash_profile?

Question

I understand the difference between .bashrc and .bash_profile (or .bash_login and ~/.profile for that matter), but is there any particular reason to choose .bashrc over .bash_profile for bash shell configuration?

From my understanding, configuration such as terminal colors, environmental variables, etc. in .bashrc will be re-loaded every time a new bash window is open. .bash_profile will only get loaded once at login, and I think that should be enough. Why put anything in .bashrc then?

The only reason I can think of is to avoid having to log out of the system for a configuration to be loaded.

I couldn't find an answer besides purely conventional reasons.

Answer 1

Shell options (from shopt or set) are not inherited through the environment. Nor are aliases. If you want to, for example, enable failglob for all your shells, that needs to be in the RC file. An alias could be replaced with an exported function, but there's no workaround for the options.

It is also conventional & encouraged by the manual to have .bash_profile source .bashrc, so these configurations that you put in there will be loaded into both login and non-logic shells. If they're only in .bash_profile, they might never be loaded into a shell you actually use at all.

Another situation is where you have more complex configuration with actual executable code (for example, some advanced PROMPT_COMMAND) and want freshly-initialised variables for it to use in each shell. You probably wouldn't want those variables exported at all, or perhaps they are arrays and they can't be.

A final case would be for side-effecting command execution: displaying fortune or a to-do list in every new shell. That is not so much "configuration", but it is setting up your shell behaviour.

---

There is also the more general case where bash is not invoked as the login shell (because your session manager does something else, or it isn't your login shell, or ...) and your .bash_profile would never be processed at all. That may be out of scope for your concern, though.

Answer 2

Any functions or aliases you define will not be available in child shells if you only define them in the profile files.

You can reload these files using the source command without having to log out, but this can mangle the PATH a bit if it has been modified. . on its own is an alias for source but sometimes it gets remapped by sysadmins (not sure of the reason).

This is also why you need to run the source command to create functions and aliases in the running shell, because running the script on its own will create a new shell, then create them in that shell and not in the one you're using.