(这可能是一个矫枉过正,但也许它会很有用)
需要记住的一些事项:
环境变量在某种程度上是公开的,其他进程可以很容易地看到,就像在ps(1)
命令中添加一个选项(如ps e $$
在 bash 中)或查看/proc/*/environ
,尽管在现代系统上两者都至少限制为同一个用户(或 root)。如果您有另一个相当简单的选择,请不要依赖它们是秘密的。
~/.bashrc
是环境变量的错误位置,因为它们可以在登录时计算一次~/.bash_login
,〜/ .bash_profile,或~/.profile
根据您的使用情况,并传递给所有后代shell。相比之下,~/.bashrc
动作往往会在每次 shell 调用时重新计算(除非明确禁用)。
将 bash 代码放入其中~/.profile
可能会混淆其他 sh-descendent shell 和尝试读取该文件的非 shell 工具,因此让 bash-specific~/.bash_login
或 -_profile 包含 bash-specific 的东西,并. ~/.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 中都不应该有命令名扩展。
sudo
正如 ybakos 指出的那样,大多数环境变量在root 时都会被丢弃。类似的问题出现在 crontabs、jobs 等中。如果有疑问,添加env | sort > /tmp/envvars
或类似的可疑脚本确实有助于调试。
请注意,某些发行版的 shell 启动脚本如此扭曲,最终实际上违反了 bash(1) 手册页中给出的顺序。每当您发现默认用户~/.profile
检查 $BASH 或 $BASH_VERSION 时,您可能处于其中一个,嗯...,“有趣”的环境中,并且可能必须通读它们以找出控制流的去向(他们应该使用特定于 bash 的~/.bash_profile
or ~/.bash_login
,其中包含更通用~/.profile
的引用,从而让 bash 可执行文件完成工作,而不必在 shell 代码中编写 $BASH 检查)。
~/.bash_profile
(或~/.bash_login
)当然可以包括. ~/.bashrc
,但环境变量属于~/.bash_profile
(如果特定于bash)或~/.profile
包含在其中(如果您使用此机制并且其中包含其他所有内容的环境变量),正如DeWitt所说,只要记住把. ~/.bashrc
.bash_profile. ~/.profile
和其他环境变量之后,以便登录和所有其他调用都~/.bashrc
可以依赖已经设置的环境变量。一个例子~/.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 的角度来看,其他两个的使用完全在用户的控制之下。