相关疑难解决方法(0)

我一直看到引用此链接的答案明确指出“不要解析ls！” 这让我感到困扰有几个原因：

1. 似乎该链接中的信息已被批量接受，几乎没有问题，尽管我可以在随意阅读中至少挑出一些错误。

2. 该链接中所述的问题似乎也引发了不想找到解决方案的愿望。

从第一段：

...当你要求[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 …

这个问题的灵感来自

为什么使用 shell 循环处理文本被认为是不好的做法？

我看到这些结构

for file in `find . -type f -name ...`; do smth with ${file}; done

和

for dir in $(find . -type d -name ...); do smth with ${dir}; done

几乎每天都在这里使用，即使有些人花时间对这些帖子发表评论，解释为什么应该避免这种东西......
看到此类帖子的数量（以及有时这些评论被简单地忽略的事实）我想我还不如问一个问题：

为什么循环find的输出是不好的做法，为 返回的每个文件名/路径运行一个或多个命令的正确方法是find什么？