问为什么使用“AC.26”或"&“来提供不同大小的结果文件？

EN

这个答案中的一些细节假设用户使用的是zsh以外的shell。由于zsh的原因，它的MULTIOS功能的详细信息略有不同。

1. strings *.bin > bin.txt | sort -n bin.txt > logs1.txt运行strings *.bin并将结果重定向到bin.txt。在strings启动的同时，启动sort并对文件bin.txt进行排序。管道除了允许这两个命令并发运行之外，在这个管道中完全没有任何功能。通常，管道用于将左侧命令的标准输出传递到右侧命令的标准输入，但由于这两个命令都是从文件中读取的，所以从不使用管道。由于strings和sort都是同时启动的，sort可能会在strings完成整个文件编写之前找到bin.txt文件的结尾。如果有的话，sort将读取多少数据，这是相当随机的。正确使用管道看起来就像字符串--在这里，*.bin收排序-n > logs1.txt，strings直接写入sort的输入，而不是文件，sort从strings的输出而不是从文件中读取。如果左手侧不能产生足够快的数据，则管道的右侧将被暂时阻塞；如果右侧不能足够快地消耗数据，则左侧将被暂时阻塞。这样，这两个实用程序是同步的，您可以保证sort将读取strings的全部输出。
2. strings *.bin > bin.txt & sort -n bin.txt > logs1.txt的问题与前面的命令相同，因为strings和sort都是同时启动的。&在后台启动strings，然后立即启动sort。这两个实用程序都是相互独立地写入或从bin.txt读取的，这很有可能决定在sort结束之前写入了多少文件。
3. strings *.bin > bin.txt其次为sort -n bin.txt > logs2.txt。在这里，通过允许strings在使用sort对其内容排序之前完成对中间文件bin.txt的写入，手动同步这两个实用程序。没有问题，您可以保证sort将能够从文件中读取strings的完整输出。

汇总：前两个命令不同步strings和sort实用程序。strings的写作与sort的阅读无关。这意味着sort可能在strings完成编写所有数据之前找到中间文件的结尾。反过来，这意味着你可能得到一个不完整的结果。不完整结果包含的数据量取决于偶然。

这两个实用程序是同时启动的，这也意味着sort甚至可以在shell有时间截断文件并启动strings之前将预先存在的bin.txt读取到末尾。

解决方案：首先将所有数据写入中间文件，然后从中间文件中读取数据，如第三个示例所示。或者，允许这两个实用程序使用管道在它们之间直接通信数据，如我上面的建议所示：

strings -- *.bin | sort -n > logs1.txt

或保留未排序的strings输出的副本，以供以后参考：

strings -- *.bin | tee bin.txt | sort -n > logs1.txt

关于U&L的进一步相关解读：

• 外壳的控制和重定向操作符是什么？
• “-”(双冲)是什么意思？