为什么Ubuntu的默认〜/ .profile源〜/ .bashrc？

这些是~/.profile我的13.10附带的库存内容（已删除注释行）：

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

这是从Debian继承的，但是Canonical为什么决定保留它？据我所知，这不是标准的* nix方式，而且我已经看到各种系统都没有发生这种情况，因此我认为它们一定有充分的理由。当运行用户不希望获得~/.bashrc源代码的登录Shell（例如，在ssh进入计算机）时，这可能会导致意外行为。

我能想到的唯一好处是，不会使用户混淆许多启动文件，并允许他们.bashrc单独编辑并可以读取该文件，而不管外壳类型如何。但是，这是一个可疑的好处，因为为登录名和交互式shell设置不同的设置通常很有用，这会阻止您这样做。此外，登录外壳程序通常不在图形环境中运行，这可能会导致错误，警告和问题（哦，天哪！），具体取决于您在这些文件中设置的内容。

那么，为什么Ubuntu会这样做，我想念的是什么？

这是Debian做出的上游决定。在这个非常不错的Wiki帖子中解释了它的基本原理，以下是摘录。执行摘要是“确保GUI和非GUI登录以相同的方式工作”：

让我们以xdm为例。pierre有一天从假期回来，发现他的系统管理员已在Debian系统上安装了xdm。他登录正常，xdm读取他的.xsession文件并运行fluxbox。一切似乎都还不错，直到他在错误的语言环境中收到错误消息为止！由于他覆盖了.bash_profile中的LANG变量，并且由于xdm从不读取.bash_profile，因此现在将其LANG变量设置为en_US而不是fr_CA。

现在，这个问题的简单解决方案是他可以将窗口管理器配置为启动“ xterm -ls”，而不是启动“ xterm”。该标志告诉xterm，它应该启动登录shell，而不是启动普通的shell。在这种设置下，xterm生成/ bin / bash，但是将“-/ bin / bash”（或者也许是“ -bash”）放在参数向量中，因此bash的作用类似于登录shell。这意味着，每当他打开一个新的xterm时，它将读取/ etc / profile和.bash_profile（内置的bash行为），然后读取.bashrc（因为.bash_profile表示这样做）。乍一看这似乎效果很好-他的点文件并不繁重，所以他甚至都没有注意到延迟-但还有一个更细微的问题。他还直接从其fluxbox菜单启动了网络浏览器，并且Web浏览器从fluxbox继承了LANG变量，该变量现在被设置为错误的语言环境。因此，尽管他的xterm可能很好，并且从他的xterm启动的任何东西都可能很好，但是他的Web浏览器仍然在错误的语言环境中提供页面。

那么，什么是解决此问题的最佳解决方案？确实没有通用的。更好的方法是将.xsession文件修改为如下所示：

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

这将导致解释.xsession脚本的shell在运行xmodmap或xterm或“执行”窗口管理器之前，在/ etc / profile和.bash_profile中读取它们（如果存在且可读）。但是，此方法有一个潜在的缺点：在xdm下，读取.xsession的外壳程序在没有控制终端的情况下运行。如果/ etc / profile或.bash_profile使用假定终端存在的任何命令（例如“ fortune”或“ stty”），则这些命令可能会失败。这是xdm默认不读取这些文件的主要原因。如果要使用这种方法，则必须确保在没有终端的情况下，“点文件”中的所有命令都可以安全运行。

这是Ubuntu的标准行为，~/.bashrc是用户级的每个交互式shell启动文件。基本上，当您打开终端时，您将启动一个非登录的交互式外壳 ，该外壳读取获取的~/.bashrc内容和~/.bashrc获取的内容并将其导出到当前的外壳环境中。它有助于一个人在当前shell中获取其所有用户定义的shell变量和函数。你也可以找到这样的行

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

在当前的shell环境中获取用户定义的别名。

这对于提供良好的用户体验也很重要。例如一个可以存储代理凭证的.bashrc，除非它得到采购无终端应用（即，ping，wget，curl，lynx等）将正常工作。或者，您每次打开终端时都必须提供代理凭据。

除了Ubuntu的默认.bashrc包含了许多人性化的别名（ls和grep打印输出colourized），针对不同的shell变量增加用户体验许多新的定义。

但是，如果使用ssh登录或在虚拟控制台中登录，则基本上可以获得交互式登录shell。外壳启动文件在那里~/.profile。因此，除非您找到来源，否则将~/.bashrc错过所有有用的设置.bashrc。这就是为什么Ubuntu的默认~/.profile来源~/.bashrc

要避免的情况

• 当您从中获取~/.profile表格~/.bashrc时，切勿同时在~/.bashrc其中获取表格~/.profile。它将导致情况无限循环，因此除非按Ctrl+，否则终端提示将被挂起C。在这种情况下，如果您在~/.bashrc

设置-x

然后您会看到打开终端时文件描述符正在停止。