我有以下奇怪的行为，以下文件夹存在@fortawesome
但当我按下
cd 塔基
没有出现以“@”开头的任何文件夹。为什么会发生这种情况/我该如何进一步调查？
答案1
如果您没有使用 Linux 系统创建目录，则 Bash 有可能不会完成，因此 Bash 不会将其视为文件。
Linux 中的目录实际上只是一个文件，其中包含元数据，包括“其中”文件的位置。这与 Windows 的做法大不相同。
如果该模块（假设它是一个节点模块）来自 npm，那么很有可能它是由 NTFS 文件系统生成的。
我不确定这会如何影响 bash 完成查看它的方式，但如果它没有显示，那很可能就是原因。
我如何才能进一步调查此事？
为了确保目录仍然在那里，您可以直接cd进入目录。无论哪种方式，这都会为您提供更多信息。此外，如果您有，请运行ls -a ~或。la ~
您还应该创建一个具有相同命名约定的新文件夹，以查看它是否存在相同的问题。
此外，您还可以从 apt 获取一个名为 的工具tree。它类似于 ls，但是是递归的。它将输出当前目录的整个目录结构。
要查看 Linux 是否正确“接受”了该目录，您可以检查权限。
la -a -n
注意列表中罪魁祸首目录的第一个字符。它应该是“d”。如果它是“-”，那么它根本不是一个文件夹。就操作系统而言，它现在是一个文件，这可能意味着里面的所有内容都被清除了。
这还将显示所有者和组信息。如果它具有所有这些属性，那么它肯定会显示出来。
在这种情况下，请重新运行上述过程并截取每个过程的结果。如果您将它们添加到您的问题中，我保证有人会知道发生了什么。
编辑：
虽然我很高兴你找到了这个问题的解决方案，但我仍然不禁想知道为什么你的机器会出现这种情况，而我的机器不会。正如我之前提到的，我简单地测试了我的 Ubuntu
（Ubuntu = 版本 20.04.2 -- bash = 版本 5.0.17release）
通过创建一个@test目录并检查在同一父目录中运行各种命令和应用程序的结果。在你发现可以退出之前，我就这么做了。问题是它们都按预期工作。
如果您遇到了这种情况，并且您使用的是较新的 Ubuntu 版本，那么毫无疑问其他人也会遇到同样的问题。
目前，我认为造成这种差异的原因主要有两种。要么是我们以某种方式遇到了一些其他人尚未发现的奇怪边缘情况（这种可能性太小了，以至于我打出这个字都觉得有点尴尬……XD），要么是系统上的另一个程序正在更改 shell 的行为。
正如我在评论中暗示的那样，这可以通过操纵 shell 环境来实现。有几个环境变量（在我的 20.04 环境中有 11 个）以模式开头BASH，并直接指向 bash shell 属性。这些非常容易确定，因为它们都在运行命令时显示的列表的最开头set。如果您通过管道less，如下所示：
set | less
它们将是您在终端显示屏上看到的第一件事。虽然它们中的大多数只是作为常量来提供对脚本等中信息的访问，并显示所包含的信息（例如 BASH_VERSION），但其他变量可以控制它们引用的信息。对我来说，一个突出的变量是BASHOPTS。如果行为实际上是变量值的结果，那么这个变量就很有可能是罪魁祸首。
也就是说，整个环境的一个主要目的是操纵 shell 的行为。因此，它可以是环境中的任何变量……或完全不同的东西。
我继续排除此故障的目的是，如果其他人来这里寻找此问题的解决方案，他们不仅知道如何解决这个问题，而且还知道如何导致这个问题。
目前网络上关于这个问题的信息很少（我根本找不到任何信息），这本身就说明了很多问题。但事实并非如此。没有答案已经够罕见了，但没有问题几乎是闻所未闻的。通常某个地方的某个人遇到过同样的问题并发布了相关帖子。
笔记：
经过 '这是可能的”，我的意思是在一般意义上操纵 bash 的行为。我不知道是否有可能修改 bash 认为是“特殊”的字符。话虽如此，我看不出还有其他可接受的结论。我不得不花点时间才能得出这个结论。如果其他人有任何想法，我愿意洗耳恭听。
答案2
因为 @ 是一个特殊字符，所以在开头添加反斜杠可以解决问题。即，cd \@tab
同时正确自动完成文件夹的名称。