5

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.

5

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.

  • So in essence, only variables that were set to the environment by a login shell are in context for a non-login shell? I think this answers my question. Thank you – SamuelN Nov 15 '17 at 22:57
  • Nothing from the profile other than exported variables and exported functions will be automatically provided to independent subprocess shells. There may be other variables, etc, that came from somewhere else. – Michael Homer Nov 16 '17 at 0:43
1

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.

  • 1
    Functions can be exported with export -f (with Bash). – Michael Homer Nov 15 '17 at 22:21
  • I didn't know that. It does add an extra thing to remember to do, though :) – Ghoti Nov 15 '17 at 22:24
  • 1
    Just did some research - it might be insecure and leave you with obscure breaks in places, apparently. Shellshock was based on exported functions, but I believe that was fixed. – Ghoti Nov 15 '17 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.