我理解并接受防御性1 shell 脚本既谨慎又从长远来看更可持续的前提。
此处的许多文本处理问题的答案都遵循这一原则，将非正统文件名的意外情况纳入到答案中；可能包含空格、破折号和换行符。
文件名中的新行有多普遍？具体来说：
[1] 意味着规划和管理尽可能广泛的场景和突发事件......
我很难理解文件名编码是如何工作的。在 unix.SE 上，我发现了相互矛盾的解释。
引用另一个答案： 关于 linux 上文件系统字符编码的几个问题
[...] 正如您在问题中提到的，UNIX 文件名只是一个字符序列；内核对编码一无所知，这完全是一个用户空间（即应用程序级）概念。
如果文件名存储为字符，则必须涉及某种编码，因为最终文件名必须以位或字节序列的形式出现在磁盘上。如果用户可以选择任何编码将字符映射到提供给内核的字节序列，则可以为有效文件名创建任何字节序列。
假设如下： 用户使用随机编码X，将文件foo转换为字节序列? 并将其保存到磁盘。另一个用户使用编码Y。在这种编码中？转换为/，不允许作为文件名。但是，对于第一个用户，该文件是有效的。
我认为这种情况不会发生。
引用另一个答案： Linux 上的文件名和路径使用什么字符集编码？
正如其他人所指出的，对此并没有真正的答案：文件名和路径没有编码；操作系统只处理字节序列。个别应用程序可能会选择将它们解释为以某种方式编码，但这会有所不同。
如果系统不处理字符，如何在文件名中禁止特定字符（例如/或NULL）？没有/
没有编码的概念。
一种解释是文件系统可以存储包含任何
字符的文件名，并且只有考虑编码的用户程序才会阻塞包含无效字符的文件名。反过来，这意味着文件系统和内核可以毫无困难地处理包含/.
我也认为这是错误的。
编码在哪里进行，不允许特定字符的限制在哪里？
ls似乎有许多对我来说很奇怪的限制，这些限制未包含在其开关中（例如--max-depth=其他工具所具有的）。我喜欢维护通用标准（因此ls并ll遵循大多数普通发行版所具有的标准），但我的其他别名遵循某种易于记住的语法（lls“长列表、安全性”等）。我可以将其分成几个不同的问题，但由于这一切都与寻找通用操作方法的尝试有关ls，因此列出我的工作清单来描述我正在谈论的内容感觉更合适，因为它们都是相关的。一些具体问题：
我经常听到有人说你永远不应该ls在for循环等中使用。这在默认情况下如何查看子目录等方面是有意义的ls，但是有没有一种简单的方法可以剪辑ls以从不查看子目录内部？我--max-depth=在man页面中没有看到任何类似的内容，但在我看来，如果我们剪辑ls不进入子目录，那么在循环或其他结构中使用应该是可靠的for。是否有一种可靠的方法来剪辑ls为仅一个目录的输出，然后在 for 循环中使用它？
我使用了我认为相当笨重的结构lld（带有目录的长列表）和llf（带有文件的长列表）。有没有更好的方式来表达“我只想查看文件”？或“我只想查看目录？”；再次， man页面中我看不到任何内容。特别是，我只能以-l格式进行此列表，否则我无法 grep 出我不想显示的项目。一般来说，我认为以这种方式使用 grep 可能是一个坏主意（因为锁定-l格式），那么有没有更好的方法来实现仅选择目录项或仅选择文件，而不是使用 grep ？
如果下面的任何其他方法格式错误，我希望知道更好的方法？
尝试拥有一组标准的ls输出（每个发行版的设置通常不同）。
字符[]集通配符。例如ls name[03][17].c, 将匹配name01.c, name07.c, name31.c, name37.c, 并且[]还允许范围：ls name[07][1-9].c
请注意使用\ls来运行裸命令，忽略别名。