bash 进程替换和尾部结果不正确？

使用 bash 进程替换，我想同时在一个文件上运行两个不同的命令。在此示例中，这不是必需的，但想象一下“cat /usr/share/dict/words”是一个非常昂贵的操作，例如解压缩 50gb 文件。

cat /usr/share/dict/words | tee >(head -1 > h.txt) >(tail -1 > t.txt) > /dev/null

执行此命令后，我希望 h.txt 包含单词文件“A”的第一行，t.txt 包含文件“Zyzzogeton”的最后一行。

然而实际发生的情况是 h.txt 包含“A”，但 t.txt 包含“argillaceo”，大约占文件的 5%。

为什么会发生这种情况？看起来要么“尾部”进程提前终止，要么流正在混淆。

运行另一个类似的命令，如下所示，其行为符合预期：

cat /usr/share/dict/words | tee >(grep ^a > a.txt) >(grep ^z > z.txt) > /dev/null

在这个命令之后，我希望 a.txt 包含所有以“a”开头的单词，而 z.txt 包含所有以“z”开头的单词，这正是发生的情况。

那么为什么这不适用于“tail”，以及其他哪些命令这不起作用？

好吧，似乎发生的事情是一旦head -1命令完成后退出，这会导致tee为了获得 SIGPIPE，它尝试将进程替换设置写入命名管道，该管道生成一个EPIPE并根据man 2 write也会产生SIGPIPE在写作过程中，导致tee退出并迫使tail -1立即退出，并且cat左边有一个SIGPIPE以及。

如果我们在流程中添加更多内容，我们可以更好地看到这一点head并使输出更可预测并且也写入stderr不依赖于tee:

for i in {1..30}; do echo "$i"; echo "$i" >&2; sleep 1; done | tee >(head -1 > h.txt; echo "Head done") >(tail -1 > t.txt) >/dev/null

当我运行时它给了我输出：

1
Head done
2

所以在一切退出之前它只进行了 1 次循环迭代（尽管t.txt仍然只有1在里面）。如果我们那么做

echo "${PIPESTATUS[@]}"

we see

141 141

which 这个问题 https://stackoverflow.com/questions/19120263/why-exit-code-141-with-grep-q与SIGPIPE以与我们在这里看到的非常相似的方式。

coreutils 维护者已将此作为示例添加到他们的tee“陷阱” http://www.pixelbeat.org/docs/coreutils-gotchas.html#tee为了未来的子孙后代。

要与开发人员讨论这如何符合 POSIX 合规性，您可以在以下位置查看（已关闭的 notabug）报告：http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22195 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22195

如果您可以访问 GNU 版本 8.24，他们添加了一些可以提供帮助的选项（不在 POSIX 中），例如-p or --output-error=warn。如果没有它，您可以冒一点风险，但通过捕获和忽略 SIGPIPE 来获得问题中所需的功能：

trap '' PIPE
for i in {1..30}; do echo "$i"; echo "$i" >&2; sleep 1; done | tee >(head -1 > h.txt; echo "Head done") >(tail -1 > t.txt) >/dev/null
trap - PIPE

都会得到预期的结果h.txt and t.txt，但是如果发生了其他需要正确处理 SIGPIPE 的事情，那么您将无法使用这种方法。

另一个黑客选项是归零t.txt在开始之前不要让head进程列表完成直到其长度非零：

> t.txt; for i in {1..10}; do echo "$i"; echo "$i" >&2; sleep 1; done | tee >(head -1 > h.txt; echo "Head done"; while [ ! -s t.txt ]; do sleep 1; done) >(tail -1 > t.txt; date) >/dev/null