在 bash 中同时连接标准输出和标准错误？答案

【问题标题】：Piping both stdout and stderr in bash?在 bash 中同时连接标准输出和标准错误？
【发布时间】：2013-05-06 00:38:45
【问题描述】：

似乎较新版本的 bash 具有 &> 运算符，它（如果我理解正确的话）将 stdout 和 stderr 都重定向到文件（&>> 改为附加到文件中，正如 Adrian 澄清的那样）。

实现相同目的的最简单方法是什么，而不是管道到另一个命令？

例如，在这一行中：

cmd-doesnt-respect-difference-between-stdout-and-stderr | grep -i SomeError

我希望 grep 匹配 stdout 和 stderr 中的内容（实际上，将它们合并到一个流中）。

注意：这个问题询问的是管道，不是重定向 - 所以它不是它当前标记为重复的问题的重复。

【问题讨论】：

查看链接问题的第二个答案 (stackoverflow.com/a/637834/1129642) 以了解管道 stdout 和 stderr 的正确方法。不需要再问了。
@triplee 不是完全重复的，是吗？管道与重定向到文件？
@BenjaminW 至少有一个答案可以解决这两种情况，尽管它不是公认的答案。这是一个相当常见的问题，因此我们可能会找到更好的副本，或者请版主合并这些 - 甚至在最坏的情况下，为这个主题制作一个全新的规范。如果你找到一个更好的骗子，一定要提出来。提前致谢。
@tripleee 解决，是的，但没有一个答案使用|& 快捷方式，我认为这是迄今为止“将标准输出和标准错误重定向到管道”最方便的解决方案。跨度>
这不是链接问题的重复，并且不清楚 Marko 的回答是否符合我的要求。此外，它没有提到|&。投票重新开放。

【解决方案1】：

（请注意，&>>file 追加到文件，而&> 将重定向并覆盖以前存在的文件。）

要结合stdout 和stderr，您可以使用2>&1 将后者重定向到前者。这会将 stderr（文件描述符 2）重定向到 stdout（文件描述符 1），例如：

$ { echo "stdout"; echo "stderr" 1>&2; } | grep -v std
stderr
$

stdout 进入标准输出，stderr 进入标准错误。 grep 只看到stdout，因此stderr 打印到终端。

另一方面：

$ { echo "stdout"; echo "stderr" 1>&2; } 2>&1 | grep -v std
$

在写入 stdout 和 stderr 之后，2>&1 将 stderr 重定向回 stdout，grep 在 stdin 上看到这两个字符串，因此将两者都过滤掉。

你可以阅读更多关于重定向here的信息。

关于您的示例（POSIX）：

cmd-doesnt-respect-difference-between-stdout-and-stderr 2>&1 | grep -i SomeError

或者，使用>=bash-4：

cmd-doesnt-respect-difference-between-stdout-and-stderr |& grep -i SomeError

【讨论】：

感谢&>> 的澄清。我已经更正了我的问题。
我将您的示例添加到我的答案中，以防万一根据我给出的示例不明显。作为旁注，您还可以使用特定于 bash 的 |& 而不是 2>&1 |。
关于@AdrianFrühwirth 为未来读者提出的快捷方式|& 的旁注：此功能仅支持bash 版本4+。如果你使用的是 3 或以下，你必须坚持使用2>&1 |。
Bash 重定向是very well explained here。 @AdrianFrühwirth 做得很好，粘贴的链接更进一步。有时，我希望官方的 Bash 文档也这么好。

【解决方案2】：

Bash 有一个 2>&1 | 的简写形式，即 |&，它同时通过管道传输 stdout 和 stderr（参见 manual）：

cmd-doesnt-respect-difference-between-stdout-and-stderr |& grep -i SomeError

这是在 Bash 4.0 中引入的，请参阅 release notes。

【讨论】：

感谢您添加此内容以确保完整性。我将保持其他答案正确，因为许多人仍在使用 bash pre-4.0。但这很有用。
最值得注意的是，macOS 上的 Bash 太旧了，无法支持。
@Flimm 但 zsh 不是
由于 ksh 使用 |& 作为 coproc，这对于不必要的速记来说似乎是一个糟糕的选择。我讨厌看到与下一个人一样多的重复和重定向的行，但是有一些要说的明确......我很抱歉，这个评论并没有增加太多。我只是想表达对速记的厌恶，而不是对一个真正有用的答案投反对票，因为人们看到这一点很好。我不知道这一点，所以谢谢你让我知道。
@PaulHodges 我同意它不可移植——我主要喜欢将它用于交互式 Bash 会话以避免输入过多。