链式命令的标准输入和命令替换中的命令

Question

让我先介绍我的发现，然后把我的问题放在最后。 (1) 仅适用于 zsh 和 (2), (3) 适用于 zsh 和 bash。

1。命令替换的标准输入

ls | echo $(cat)
ls | { echo $(cat) }

第一个打印cat: -: Input/output error；而第二个产生ls的输出。

2。管道后的链式命令

ls | { head -n1; cat}
ls | { read a; cat}

第一个命令不能正常工作。 cat遇到EOF直接退出。但第二种形式有效：第一行被读入a，cat 得到其余部分。

3。混合标准输入

ls | { python -c 'import sys; print(sys.argv)' $(head -n1) }
ls | { python -c 'import sys; print(sys.argv); print(input())' $(head -n1) }

在第一行的{}里面，命令是打印命令行参数；在第二种形式中，该命令还从stdin 中读取一行。

由于input() 读取EOF，第一个命令可以成功运行，而第二个表单抛出。

我的问题是：

1. （如第 1 节所述）带有 {} 和不带有 {} 的表单有什么区别？
2. （如第 2 节）head 和 cat 是否可以按顺序读取相同的 stdin？第二种形式如何成功，第一种形式失败？
3. （如第 3 节所述）命令替换中命令的stdin 如何连接到原始命令的标准输入（此处为echo）。谁先读？以及如何使stdin 保持打开状态，以便两个命令（python 和head）可以顺序读取相同的stdin？

Answer 1

您没有考虑输入缓冲，它解释了您的大部分观察结果。

head 每次需要数据时都会读取几千字节的输入，这使其效率更高。因此，它很可能会在任何其他进程有机会之前读取所有标准输入。这在案例 2 中很明显，执行顺序可能更清晰。

如果输入来自常规文件，head 可以在终止之前返回到它使用的行的末尾。但是由于管道是不可搜索的，它不能那样做。如果您使用“here-strings”——<<< 语法，那么 stdin 将变成可搜索的，因为 here-strings 是使用临时文件实现的。不过，我不知道你是否可以相信这个事实。

read 不缓冲输入，至少不超出当前行（即使那样，只有在命令行上没有指定其他行结束分隔符时）。它只仔细阅读它所需要的内容，因为它通常用于其输入来自管道并且不可能进行搜索的上下文中。这非常有用——以至于它的工作原理几乎是不可见的——但这也是 shell 脚本可能非常缓慢的原因之一。

通过将足够的数据发送到管道以满足head 的初始读取，您可以更清楚地看到这一点。试试这个，例如：

seq 1 10000 | { head -n1; head -n2; }

（我将第二个head 更改为head -n2，因为第一个head 恰好将stdin 定位在行尾，因此第二个head 将空行视为第一个行。）

您需要了解的另一件事是命令替换的作用和时间。命令替换读取命令的整个输出并将其插入命令行。甚至在命令被识别之前就会发生这种情况，更不用说开始执行了。

考虑以下小sn-p：

$(printf %cc%co e h) hello, world

应该清楚的是，命令替换是在 echo 实用程序（或内置）启动之前完全执行的。

您的第一个场景触发了zsh 的奇怪之处，Stéphane Chazelas 在this answer on Unix.SE 中对此进行了解释。实际上，zsh 在管道设置之前 执行命令替换，因此cat 正在从主 zsh 的标准输入读取。 （Stéphane 解释了为什么会这样以及它是如何导致 EIO 错误的。虽然我认为这取决于精确的 zsh 配置和选项设置，但在我的默认 zsh 安装中，它只是锁定了我的终端。在某些时候我会必须弄清楚原因。）如果使用大括号，则在执行命令替换之前设置重定向。