或者，有关强大的文件名处理和在 shell 脚本中传递的其他字符串的介绍性指南。
我写了一个 shell 脚本，它在大多数情况下运行良好。但它在某些输入（例如某些文件名）上窒息。
我遇到了如下问题：
hello world，它被视为两个单独的文件hello和world.\[*?，它们会被一些文本替换，这实际上是文件的名称。'（或双引号"），在那之后事情变得很奇怪。\分隔符）。这是怎么回事，我该如何解决？
我一直看到引用此链接的答案明确指出“不要解析ls！” 这让我感到困扰有几个原因：
似乎该链接中的信息已被批量接受，几乎没有问题，尽管我可以在随意阅读中至少挑出一些错误。
该链接中所述的问题似乎也引发了不想找到解决方案的愿望。
从第一段：
...当你要求
[ls]一个文件列表时，有一个大问题：Unix 允许文件名中的几乎任何字符，包括空格、换行符、逗号、管道符号，以及几乎任何你曾经尝试用作除 NUL 外的分隔符。...ls用换行符分隔文件名。这很好，直到您的文件名称中包含换行符。并且由于我不知道任何ls允许您使用 NUL 字符而不是换行符终止文件名的实现，这使我们无法使用ls.
无赖，对吧？如何以往我们可以处理一个换行符终止的上市数据集可能包含换行符的数据？好吧，如果这个网站上回答问题的人不是每天都做这种事情，我可能会认为我们遇到了麻烦。
事实是，大多数ls实现实际上提供了一个非常简单的 api 来解析它们的输出，我们一直在做，甚至没有意识到。您不仅可以以 null 结束文件名，还可以以 null 或您可能需要的任何其他任意字符串开头。更重要的是，您可以为每个文件类型分配这些任意字符串。请考虑：
LS_COLORS='lc=\0:rc=:ec=\0\0\0:fi=:di=:' ls -l --color=always | cat -A
total 4$
drwxr-xr-x 1 mikeserv mikeserv 0 Jul 10 01:05 ^@^@^@^@dir^@^@^@/$
-rw-r--r-- 1 mikeserv mikeserv 4 Jul 10 02:18 ^@file1^@^@^@$
-rw-r--r-- 1 mikeserv mikeserv 0 Jul 10 01:08 ^@file2^@^@^@$
-rw-r--r-- 1 mikeserv mikeserv 0 Jul …如果您已经关注 unix.stackexchange.com 一段时间了，那么您现在应该知道，echo $var在 Bourne/POSIX shell（zsh 是例外）中的列表上下文（如）中不加引号的变量具有非常特殊的含义，并且除非你有很好的理由，否则不应该这样做。
在这里的许多问答中详细讨论了它（例如：为什么我的 shell 脚本会因空格或其他特殊字符而窒息？，何时需要双引号？，shell 变量的扩展以及 glob 和 split 对其的影响，引用vs 不带引号的字符串扩展)
自从 70 年代末 Bourne shell 首次发布以来就是这种情况，并且没有被 Korn shell 改变（David Korn 最大的遗憾之一（问题 #7））或者bash大部分复制了 Korn shell，这就是POSIX/Unix 是如何指定的。
现在，我们仍然在这里看到许多答案，甚至偶尔会公开发布未引用变量的 shell 代码。你会认为人们现在已经学会了。
根据我的经验，主要有 3 类人会省略引用他们的变量：
初学者。这些可以被原谅，因为它是一种完全不直观的语法。我们在这个网站上的职责是教育他们。
健忘的人。
即使经过反复锤击也不相信的人，他们认为Bourne shell 的作者肯定没有打算让我们引用所有变量。
如果我们揭露与此类行为相关的风险，也许我们可以说服他们。
如果您忘记引用变量，那么最糟糕的事情是什么。真的有那么糟糕吗？
我们在这里谈论什么样的漏洞？
在什么情况下会出现问题？
关于该错误的一些上下文：CVE-2014-6271
Bash 不仅支持将 shell 变量导出，还支持将 shell 函数导出到其他 bash 实例，通过进程环境到（间接）子进程。当前的 bash 版本使用由函数名称命名的环境变量，以及变量值中以“() {”开头的函数定义，以通过环境传播函数定义。该漏洞的出现是因为bash在处理函数定义后没有停止；它会按照函数定义继续解析和执行 shell 命令。例如，环境变量设置
Run Code Online (Sandbox Code Playgroud)VAR=() { ignored; }; /bin/id将环境导入 bash 进程时执行 /bin/id 。
资料来源：http : //seclists.org/oss-sec/2014/q3/650
该错误是什么时候引入的，完全修复它的补丁是什么？（参见CVE-2014-7169）
除了 CVE（最初）（3.{0..2} 和 4.{0..3}）中提到的易受攻击版本之外，还有哪些易受攻击的版本？
有问题的源代码是否在其他项目中重用？
需要额外的信息。