The Environment File

Although environment variables will always be known to subprocesses, the shell must be explicitly told which other variables, options, aliases, and so on, are to be communicated to subprocesses. The way to do this is to put all such definitions into the environment file. bash's default environment file is the .bashrc file that we touched on briefly at the beginning of this chapter.

Remember, if you take your definitions out of .bash_profile and put them in .bashrc, you will have to have the line source .bashrc at the end of your .bash_profile so that the definitions become available to the login shell.

广告:个人专属 VPN,独立 IP,无限流量,多机房切换,还可以屏蔽广告和恶意软件,每月最低仅 5 美元

The idea of the environment file comes from the C shell's .cshrc file. This is reflected in the choice of the name .bashrc. The rc suffix for initialization files is practically universal throughout the UNIX world.[24]

As a general rule, you should put as few definitions as possible in .bash_profile and as many as possible in your environment file. Because definitions add to rather than take away from an environment, there is little chance that they will cause something in a subprocess not to work properly. (An exception might be name clashes if you go overboard with aliases.)

The only things that really need to be in .bash_profile are environment variables and their exports and commands that aren't definitions but actually run or produce output when you log in. Option and alias definitions should go into the environment file. In fact, there are many bash users who have tiny .bash_profile files, e.g.:

stty stop ^S intr ^C erase ^?
date
source .bashrc

Although this is a small .bash_profile, this user's environment file could be huge.

 


[20] Unless automatic exporting has been turned on by set -a or set -o allexport, in which case all variables that are assigned to will be exported.

[21] There is an obscure option, set -k, that lets you put this type of environment variable definition anywhere on the command line, not just at the beginning.

[23] Note that most modern UNIX systems now use a database rather than a flat file for the terminal descriptions.

[24] According to the folklore, it stands for "run commands" and has its origins in old DEC operating systems.