为什么默认情况下仍然启用 bash 历史替换？

Question

有人知道为什么 bash 仍然默认启用历史替换吗？我的.bashrc已经包含set +H很多年了，但其他一些人仍然被这个功能所吸引。

鉴于几乎每个人都使用具有复制粘贴功能的终端，并且使用readline库编译的 bash和历史替换在默认情况下仅在交互式 shell 中启用，真的有任何理由拥有该功能吗？即使默认情况下为所有 shell 禁用此功能，也不会破坏现有脚本。

如果你不知道为什么历史替换被破坏，试试这个：

$ set +H # disable feature history substitution
$ echo "WTF???!?!!?"
WTF???!?!!?
$ set -H # enable feature history substitution
$ echo "WTF???!?!!?"
echo WTF???echo WTF???!?!!?
WTF???echo WTF???!?!!?

（显然，如果默认情况下所有脚本都禁用该功能，并且存在一个功能可以在执行之前验证结果，则该功能存在重大问题：shopt -s histverify。）

也可以看看：

• 为什么感叹号 `!` 有时会打乱 bash？
• 为什么 Bash 历史记录没有记录这个命令？
• 如何呼应一声巨响！
• Bash：在同一行内的双引号后单引号内的历史扩展

Answer 1

如果您已经熟悉bash，那么处理历史替换模式并不比处理任何其他对这个 shell 特殊的字符更容易咬你。但是，如果不熟悉 shell 或者只是从未使用过它的历史替换功能，那么当看似无害的未引用或双引号字符串触发它时，显然会感到惊讶。

在启用历史替换的交互式 shell 中，该!字符的特殊性与该字符的特殊性几乎相同$，即无处不在，除非使用\单引号字符串或在单引号字符串中进行转义。

与$通过相反，历史替换不会在此处文档中扩展，并且由于它们是面向行的，因此它们还会 发生在替换属于未引用上下文或双引号上下文的行（单独扫描时在该行中） . 有关详细信息，请参阅此错误报告。

在非交互式 shell（脚本）中禁用历史替换是因为那里不需要 shell 的命令历史功能，而不是因为该功能有“主要问题”。在脚本中，将每个命令保存为$HISTFILE没有意义，历史替换同样不是您希望在脚本中依赖的东西。

是否应该在交互式 shell 中默认启用它是有争议的（尽管我并不完全相信这里的辩论对bash开发人员来说很重要）。你似乎认为大多数bash用户都遇到了历史扩展的问题，但你我谁都不知道使用它们有多普遍。

Unix shell 允许修改 shell 的行为以适应个人的需要和品味。如果您想关闭所有交互式 shell 的历史替换，请继续执行您set +H在~/.bashrc文件中使用的操作，或游说bash开发人员更改默认设置（我相信，这会让更多人感到不安和困惑，而不是帮助）。

Answer 2

历史替换很有用。以

% make-me-a-sandwich
make-me-a-sandwich: Permission denied
% sudo !!
Ok.

Answer 3

社会/文化惰性。

这个问题属于人类如何工作的问题空间，所以我将从这个角度回答，而不对该功能是否应该默认启用提出任何意见。

首先，为了确保你理解对方，请考虑一下，你对不得不特意关闭该功能所感到的烦恼，就是如果他们不得不特意打开该功能也会感到的烦恼该功能。

结合上述情况，再加上有足够多的bash用户确实使用该功能，默认情况下删除或关闭它的建议遭到了那些已经习惯默认情况下存在的人的抵制。

此外，bash它是许多人的默认 shell（不仅仅是在默认登录或系统 shell 意义上，而且在心理意义上）。如果您的 shell 引用的参考框架是bash，如果这是您首先学习的 shell，那么它!是一个特殊的 shell 字符这一事实对您来说会感觉自然且自动（或者至少，当您第一次学习它时，它将只是shell 的方式只是众多怪癖中可以接受的一个）。

如果你想一想，很多用户可能会在积极的bash上下文中遇到历史替换语法：他们读到它或有人向他们展示它，并且当他们第一次学习时，他们看到它可能的用处。bash

它只是来自其他类似 Bourne 的 shell 的外围世界，你会被它的!特殊性所困扰，从而倾向于消极地看待它：因为如果你习惯了从未有过该功能的 shell，那么你的第一个当你试图匆忙完成某件事时，它就会让你陷入困境。

TL;DR：大多数用户可能不太关心默认值是什么，有些用户喜欢该功能，并且已经具有这种功能的强大优势，而且还没有足够多的人积极反对该功能克服这一点。