(这可能有点矫枉过正,但也许会有用)
注意事项:
环境变量在某种程度上是公开的,其他进程可以很容易地看到,就像在ps(1) 命令中添加一个选项(如 bash 中的ps e $$)或查看/proc/*/environ,尽管两者都至少被限制为现代系统上的相同用户(或 root)。如果您有其他相当简单的选择,请不要指望它们保密。
~/.bashrc 是环境变量的错误位置,因为它们可以在登录时计算一次 ~/.bash_login、~/.bash_profile 或 ~/.profile,具体取决于您的使用情况,并传递给所有后代 shell。相比之下,~/.bashrc 操作往往会在每次 shell 调用时重新计算(除非明确禁用)。
将 bash 代码放入 ~/.profile 会混淆其他 sh 后裔 shell 和尝试读取该文件的非 shell 工具,因此 bash 特定的 ~/.bash_login 或 -_profile 包含 bash 特定的东西,并且将. ~/.profile 用于更一般的事情(LESS、EDITOR、VISUAL、LC_COLLATE、LS_COLORS 等)对其他工具更友好。
~/.profile 中的环境变量应采用旧的 Bourne shell 形式 (VAR=value ; export VAR)。在 Linux 上,这通常并不重要,但在其他 Unixen 上,当旧版本的“sh”试图读取它们时,这可能是一个大问题。
某些 X 会话只会读取 ~/.profile,而不是 ~/.bash_login 或上面提到的其他会话。有些人会寻找~/.xsession 文件,如果它还没有,则需要修改为. $HOME/.profile。
系统范围的设置将被放在类似/etc/profile.d/similar-to-heroku.sh 的地方。请注意,“.sh”仅存在,因为该文件将与“.”一起使用。或 "source" - shell 脚本应该从不在任何形式的 Unix/Linux 中具有命令名称扩展名。
正如 ybakos 指出的那样,当一个 sudos 成为 root 时,大多数环境变量都会被丢弃。类似的问题出现在 crontabs、jobs 等中。如果有疑问,添加 env | sort > /tmp/envvars 或类似的可疑脚本确实有助于调试。
请注意,某些发行版的 shell 启动脚本如此扭曲,以至于实际上违反了 bash(1) 手册页中给出的顺序。每当您发现默认用户 ~/.profile 检查 $BASH 或 $BASH_VERSION 时,您可能处于其中一个,嗯...,“有趣”的环境中,并且可能必须通读它们以找出控制流的去向(他们应该使用特定于 bash 的 ~/.bash_profile 或 ~/.bash_login,其中包括更通用的 ~/.profile 引用,从而让 bash 可执行文件完成工作,而不必在 shell 代码中编写 $BASH 检查)。
~/.bash_profile(或~/.bash_login)当然可以包含. ~/.bashrc,但环境变量属于~/.bash_profile(如果特定于bash)或其中包含的~/.profile(如果你正在使用它机制并在其中为其他所有内容提供环境变量)正如DeWitt所说,只需记住将. ~/.bashrc放在.bash_profile的. ~/.profile和其他环境变量之后,这样~/.bashrc的登录和所有其他调用都可以依赖envvars 已经被设置。一个例子~/.bash_profile:
# .bash_profile
[ -r ~/.profile ] && . ~/.profile # envvars
[ -r ~/.bashrc ] && . ~/.bashrc # functions, per-tty settings, etc.
#---eof
[ -r ... ] && ... 可以在任何 Bourne shell 后代中使用,并且如果缺少 .profile 也不会导致错误/中止(我个人也有一个 ~/.profile.d/*.sh 设置,但这留作完全可选的练习)。
请注意,bash 只读取它找到的这三个文件中的第一个文件:
~/.bash_profile
~/.bash_login
~/.profile
...所以一旦你有了那个,从 bash 的角度来看,其他两个的使用完全在用户的控制之下。