有人可以向我确认一下 Debian/Devuan/Ubuntu Linux 中的制表符完成规则是否在一段时间前发生了变化 - 以及如何（或从哪个 debian 软件包修订版）我才能快速恢复旧的行为？
细节：
我的印象是，bash 中的制表符补全已经发生了变化：
- 旧：完成总是在下一个斜杠处停止（即在进入下一个子目录之前）：
cd /m<tab>会产生：cd /mnt/然后停在那里。总是如此。
- 新增：补全尽可能深入到路径中，添加与下一个子目录中当前包含的所有文件或其他子目录相同的所有字符。
cd /m<tab>会产生：在仅包含以下内容的cd /mnt/sd
机器上：/mnt/sdb, sdc
但会产生：cd /mnt/s
在/mnt/包含sdb, sr0
但会产生：cd /mnt/
在/mnt/包含sdb, fda
[这些路径名只是简单的例子。我知道 UUID - 情况就不同了，无论如何，这会推断出更不可预测性。]
新的行为很烦人，因为它在哪个位置停止以进行新的用户输入取决于以下子目录的（变量）内容。
例如，要将某些东西挂载到/mnt/sdb1，我可能必须输入：
... /m<tab>1在一台机器上，但是
... /m<tab>b1在另一个，或
... /m<tab>sdb1又一个。
并了解自动完成功能带给我的帮助有多大，什么我必须输入下一步，我必须看着屏幕每次使用后 <tab>。
抱歉，这显然不能用。
在以前的做法中，我可以通过始终以第一的在每个新目录级别输入所需名称的 n 个字符（我知道）。这个方法非常快速，而且完全没有看在屏幕上——完全独立于下一个子目录的实际内容。
仅当我键入的字符数不足以输入下一个 时，才会发生中断<tab>；哔声会告诉我，我可以简单地添加另一个字符而不用查看 - 或者检查另一个 可用的内容<tab>。
但是，新的行为可能会在下一个斜杠后添加零个、一个或多个字符 - 甚至直接前进到一个或多个额外的子目录级别 - 完全取决于那里可用的文件。 - 所以在每个之后<tab>：没有人会提前知道它会带他们走多远，以及他们需要在哪里继续输入所需的路径名——而无需先看屏幕。
这种新行为完全破坏了任何盲打工作流程。我无法再使用自动完成功能快速编写（甚至完全已知的！）路径名 - 而无需不断检查我花了多长时间并确定接下来要输入哪个字符。 - 这使自动完成从可靠的加速变成了阻碍。
顺便说一句，从理论角度来看：为了快速到达某个地方，......
...旧的行为需要你知道你想去哪里。通过输入完全可预见的字符序列，你就能快速可靠地到达那里。
...新的行为需要你知道你想去哪里 - 但同时，还要知道周围的一切（因为这会影响下一步<tab>将带你走多远）。 - 这就是不可能的（原文如此！）。因此，它要求你检查每次之后你走了多远<tab>，并且只有在此后确定接下来要输入哪个字符才能继续。 - Brrr。
我认为“最大可能”的完成意味着“改进”，甚至被称为“更智能”。
但正如近年来常见的情况一样，这种“改进”却取得了相反的效果——将简单的确定性行为替换为无法机械使用的行为——而不先不断检查和处理屏幕输出。
我已经阅读了其他与自动完成相关的帖子，可能会查看下面的规则
/etc/bash_completion*
在尝试之前，我希望能够确认曾是变化；甚至更简单地了解何时（或为什么）会发生这种情况。然后我会尝试安装一些较旧的 bash_completion 包是否可以解决问题。
如果我对这两种方法的可用性的考虑能够得到仔细审查，并且旧规则重新确立为默认的运输行为，我会更高兴。
抱歉描述得这么长。我想确保即使是新自动完成规则的制定者也能理解这个问题。
感谢您的考虑和提前的任何提示 - Joerg