是否有任何理由避免获取 shell 的配置文件？

Question

我最近在这里阅读了一个答案，其中包括以下建议：

然而，作为一项规则，?? 你不应该source ~/.zshrc。根据您的点文件中的内容，这可能会导致各种问题。

我向 OP 询问了为什么这可能是一个问题的示例，并被告知：

因为它在您的 shell 启动时就已经获得了，并且运行命令的顺序很重要。作为一个简单的例子，放入ls() { command ls -x "$@" }; alias ls='ls -AF'你的.zshrc文件，重启你的 shell，然后source ~/.zshrc. 现在你得到一个错误zsh: defining function based on alias ls'。这只是一个相当无害的例子。事情会变得比这更毛茸茸

这听起来似乎有道理，尽管我无法用zsh. 尽管它看似合理，但我无法想象这可能会导致任何严重问题并且在打开一个干净的新会话时这些问题也不会发生的情况。我能想到的最坏情况是收到错误消息，我什至不知道如何实现。

那么，是否有充分的理由避免rc在更改shell文件后手动获取 shell文件，以便将更改导入当前 shell 会话？

我知道我多年来一直在这样做bash：我会定期添加一个功能，或者对我的功能进行更改~/.bashrc，然后再. ~/.bashrc获取它。真的有可能导致任何严重问题的情况吗？我想我们可以找到一些边缘情况，但这些足以证明这种善解人意的警告是合理的吗？也许zsh我作为bash用户还没有遇到过一些特定的事情？

我对涵盖任何 bourne-family shell（bash、sh、zsh、ksh 等）的答案感兴趣。

Answer 1

假设你的 中有这样的东西.bashrc：

foo=$(grep -m1 A /etc/os-release)
PS1="$foo %u $"
grep () { command grep -H "$@"; }

这是一种在提示符中显示发行版名称并grep始终打印文件名的快速方法，仅此而已。如果我重新获取该文件的源，我还会在提示符中获取该文件的名称。有人可能会说，这并不意外。现在想象一下，这些行之间有几十个其他的 shell 配置位，甚至可能位于不同的文件中，这些文件又由主 rc 文件来源。（最近有一个例子，某些软件为该命令创建了别名env，这可能会破坏任意数量的使用。）然后就很难预测可能会出现什么问题。

我想说，即使是自己编写的，重新获取 bashrc 也是很棘手的。足够长的 bashrc 可能会与自身产生棘手的交互。