做'cat foo.txt | my_cmd' 和 'my_cmd < foo.txt' 完成同样的事情？

Question

This question 帮助我理解了重定向和管道之间的区别，但示例侧重于重定向 STDOUT (echo foo > bar.txt) 和管道 STDIN (ls | grep foo)。

在我看来，任何可以写成my_command < file.txt 的命令也可以写成cat file.txt | my_command。什么情况下需要 STDIN 重定向？

除了使用cat 会产生一个额外的进程并且效率低于重定向STDIN 的事实之外，是否存在您必须使用STDIN 重定向的情况？换句话说，有没有理由将cat 的输出通过管道传输到另一个命令？

Answer 1

my_command < file.txt 和 cat file.txt | my_command 有什么区别？

my_command < file.txt 

重定向符号也可以写为0<，因为这会将文件描述符0 (stdin) 重定向到file.txt，而不是当前设置，这可能是终端。如果my_command 是内置的shell，则没有创建子进程，否则有一个。

cat file.txt | my_command

这会将左侧命令的文件描述符 1 (stdout) 重定向到匿名管道的输入流，并将右侧命令的文件描述符 0 (stdin) 重定向到匿名管道的输出流管道。

我们立即看到有一个子进程，因为cat 不是内置的shell。然而在bash 中，即使my_command 是一个内置的shell，它仍然在子进程中运行。因此我们有两个子进程。

因此，理论上，管道的效率较低。这种差异是否显着取决于许多因素，包括“显着”的定义。管道 更可取的时间是这种选择：

command1 > file.txt
command2 < file.txt

这里很有可能

command1 | command2

效率更高，记住，在实践中，我们可能需要rm file.txt 中的第三个子进程。

但是，管道存在限制。它们不是可搜索（随机访问，请参阅man 2 lseek）并且它们不能内存映射（请参阅man 2 mmap）。一些应用程序将文件映射到虚拟内存，但对stdin 或stdout 这样做是不寻常的。尤其是在管道上（无论是匿名的还是命名的）内存映射是不可能的，因为必须保留一定范围的虚拟地址，并且需要一个大小。

编辑：

正如@JohnKugelman 所提到的，许多 SO 问题的常见错误和来源是与子进程和重定向相关的问题：

获取一个包含 99 行的文件 file.txt：

i=0
cat file.txt|while read
do
   (( i = i+1 ))
done

echo "$i"

显示什么？答案是0。为什么？因为计数 i = i + 1 是在 subshel​​l 中完成的，在 bash 中，它是一个子进程并且不会更改父进程中的 i（注意：这不适用于 korn shell， ksh)。

while read
do
   (( i = i+1 ))
done < file.txt

echo "$i"

这会显示正确的计数，因为不涉及子进程。

Answer 2

您当然可以用从cat 读取的管道替换输入重定向的任何使用，但是这样做效率低下，因为您正在生成一个新进程来执行shell 已经可以自己执行的操作。然而，cat ... | my_command 的每个 实例都不能替换为 my_command < ...，也就是说，当 cat 正在完成连接两个（或更多）文件的预期工作时，将其通过管道传输是完全合理的。输出到另一个命令。

cat file1.txt file2.txt | my_command