如 gnu.org 文档中所述，使用 ls 列出文件是否危险？

Question

危险不仅仅在于跑步ls。危险在于键入或粘贴其输出。例如，您可以从不可信的来源获取名为&date;.如果你运行一些传统的ls（或 GNU ls -N）那么你会看到

&date;

如果您不知道在 shell 中做什么&和;做什么，那么您可以轻松运行其中之一：

nano &date;
file &date;
rm &date;
cp &date; whatever

这些命令中的任何一个都会立即运行date。date不是一个有害的命令，我特意选择了一个安全的例子。但如果文件是按字面命名的呢funny story about `rm …`.txt？噢，孩子，让我们看看吧！您甚至可能意识到带有空格的名称需要引号或转义，您有可能选择双引号；进而：

less "funny story about `rm …`.txt"

事实上，这个确切的命令几乎总是安全的（它是安全的，除非您有一个名为…您想要保留的文件），但想象一下这种情况，-rf ~用….反引号里面的会被执行无论是不带引号还是双引号。为了安全地检查文件，您应该单引号名称：

less 'funny story about `rm …`.txt'

上面的命令不会运行rm。

您链接到的文档是关于 GNU 的功能的，该功能ls旨在保护天真的用户免受此类事故的影响。它明确指出更改默认输出的原因之一是

更轻松、更安全地从终端剪切和粘贴文件名

在我们的示例文件名中，GNUls将向您显示'&date;'或'funny story about `rm …`.txt'.关键是，如果您在类似fileor 这样的命令之后准确地键入或粘贴此内容less，那么您将正确引用；也许是无意识的，但却是对的；即使您对 shell 如何解释&或反引号一无所知。

该功能比“单引号所有内容”更复杂。文件名本身可能包含单引号，因此盲目地使用单引号并不总是有效。一般来说，GNUls可以使用反斜杠、单引号、双引号，甚至ANSI-C 引用要以安全的形式显示文件名，您可以粘贴*。

^{* 并非所有 shell 都理解 ANSI-C 引用，尽管如果您使用的是 GNUls那么您可能正在使用确实理解它的现代 shell（例如 GNU bash）。此外，这并不是要创建在所有情况下粘贴时都能按预期工作的片段；而是要创建一个片段。这是为了避免那些不按预期工作的片段（或者更确切地说“按流氓作者的预期工作”）。}

Answer 1