愚蠢的解决方案:通过命名管道(mkfifo)连接它们。然后可以再次执行该命令。

 mkfifo pipe
 tee out.txt < pipe &
 command > pipe
 echo $?

有一个数组为您提供管道中每个命令的退出状态。

$ cat x| sed 's///'
cat: x: No such file or directory
$ echo $?
0
$ cat x| sed 's///'
cat: x: No such file or directory
$ echo ${PIPESTATUS[*]}
1 0
$ touch x
$ cat x| sed 's'
sed: 1: "s": substitute pattern can not be delimited by newline or backslash
$ echo ${PIPESTATUS[*]}
0 1

有一个内部Bash变量叫做$PIPESTATUS;它是一个数组，保存最后一个前台命令管道中每个命令的退出状态。

<command> | tee out.txt ; test ${PIPESTATUS[0]} -eq 0

或者另一种也适用于其他shell(如zsh)的选择是启用pipefail:

set -o pipefail
...

由于语法略有不同，第一个选项不能用于zsh。

这个解决方案不需要使用bash特定的特性或临时文件。好处:最后，退出状态实际上是一个退出状态，而不是文件中的某个字符串。

情境:

someprog | filter

您需要someprog的退出状态和filter的输出。

以下是我的解决方案:

((((someprog; echo $? >&3) | filter >&4) 3>&1) | (read xs; exit $xs)) 4>&1

echo $?

请参阅我在unix.stackexchange.com上对同一问题的回答，以获得详细的解释和没有子shell和一些注意事项的替代方案。

通过结合PIPESTATUS[0]和在子shell中执行exit命令的结果，您可以直接访问初始命令的返回值:

命令| tee;退出${PIPESTATUS[0]}

这里有一个例子:

# the "false" shell built-in command returns 1
false | tee ; ( exit ${PIPESTATUS[0]} )
echo "return value: $?"

会给你:

返回值:1

PIPESTATUS[@]必须在管道命令返回后立即复制到一个数组中。 任何对PIPESTATUS[@]的读取都将删除该内容。 如果计划检查所有管道命令的状态，则将其复制到另一个数组。 $?与${PIPESTATUS[@]}的最后一个元素值相同， 读它似乎破坏了“${PIPESTATUS[@]}”，但我还没有完全验证这一点。

declare -a PSA  
cmd1 | cmd2 | cmd3  
PSA=( "${PIPESTATUS[@]}" )

如果管道位于子外壳中，这将不起作用。为了解决这个问题， 查看bash pipestatus在backtick命令?

使用bash的set -o pipefail是有帮助的

Pipefail:管道的返回值是状态 最后一个以非零状态退出的命令， 如果没有命令以非零状态退出，则为零

在Ubuntu和Debian中，你可以apt-get install moreutils。这包含一个名为mispipe的实用程序，它返回管道中第一个命令的退出状态。

纯壳方案:

% rm -f error.flag; echo hello world \
| (cat || echo "First command failed: $?" >> error.flag) \
| (cat || echo "Second command failed: $?" >> error.flag) \
| (cat || echo "Third command failed: $?" >> error.flag) \
; test -s error.flag  && (echo Some command failed: ; cat error.flag)
hello world

现在第二只猫被false取代:

% rm -f error.flag; echo hello world \
| (cat || echo "First command failed: $?" >> error.flag) \
| (false || echo "Second command failed: $?" >> error.flag) \
| (cat || echo "Third command failed: $?" >> error.flag) \
; test -s error.flag  && (echo Some command failed: ; cat error.flag)
Some command failed:
Second command failed: 1
First command failed: 141

请注意，第一个cat也失败了，因为它的stdout关闭了。在本例中，日志中失败命令的顺序是正确的，但不要依赖它。

此方法允许捕获单个命令的stdout和stderr，以便在发生错误时将其转储到日志文件中，或者在没有错误时删除它(如dd的输出)。

所以我想提供一个类似lesmana的答案，但我认为我的答案可能更简单，更有优势的纯伯恩壳解决方案:

# You want to pipe command1 through command2:
exec 4>&1
exitstatus=`{ { command1; printf $? 1>&3; } | command2 1>&4; } 3>&1`
# $exitstatus now has command1's exit status.

我认为最好从内到外解释这一点——command1将在标准输出(文件描述符1)上执行并打印其常规输出，然后一旦完成，printf将执行并在其标准输出上打印icommand1的退出代码，但该标准输出被重定向到文件描述符3。

While command1 is running, its stdout is being piped to command2 (printf's output never makes it to command2 because we send it to file descriptor 3 instead of 1, which is what the pipe reads). Then we redirect command2's output to file descriptor 4, so that it also stays out of file descriptor 1 - because we want file descriptor 1 free for a little bit later, because we will bring the printf output on file descriptor 3 back down into file descriptor 1 - because that's what the command substitution (the backticks), will capture and that's what will get placed into the variable.

The final bit of magic is that first exec 4>&1 we did as a separate command - it opens file descriptor 4 as a copy of the external shell's stdout. Command substitution will capture whatever is written on standard out from the perspective of the commands inside it - but since command2's output is going to file descriptor 4 as far as the command substitution is concerned, the command substitution doesn't capture it - however once it gets "out" of the command substitution it is effectively still going to the script's overall file descriptor 1.

(exec 4>&1必须是一个单独的命令，因为许多常见的shell不喜欢它，当您尝试在命令替换中写入文件描述符时，该命令替换在使用该替换的“external”命令中打开。所以这是最简单的便携方法。)

You can look at it in a less technical and more playful way, as if the outputs of the commands are leapfrogging each other: command1 pipes to command2, then the printf's output jumps over command 2 so that command2 doesn't catch it, and then command 2's output jumps over and out of the command substitution just as printf lands just in time to get captured by the substitution so that it ends up in the variable, and command2's output goes on its merry way being written to the standard output, just as in a normal pipe.

另外，据我所知，$?将仍然包含管道中第二个命令的返回代码，因为变量赋值、命令替换和复合命令对于其中命令的返回代码都是有效的透明的，因此command2的返回状态应该被传播出去——这一点，而不必定义额外的函数，这就是为什么我认为这可能是一个比lesmana提出的更好的解决方案。

根据lesmana提到的警告，command1可能在某些时候最终会使用文件描述符3或4，所以为了更健壮，你会这样做:

exec 4>&1
exitstatus=`{ { command1 3>&-; printf $? 1>&3; } 4>&- | command2 1>&4; } 3>&1`
exec 4>&-

注意，我在示例中使用复合命令，但是子shell(使用()而不是{}也可以工作，尽管可能效率较低)。

Commands inherit file descriptors from the process that launches them, so the entire second line will inherit file descriptor four, and the compound command followed by 3>&1 will inherit the file descriptor three. So the 4>&- makes sure that the inner compound command will not inherit file descriptor four, and the 3>&- will not inherit file descriptor three, so command1 gets a 'cleaner', more standard environment. You could also move the inner 4>&- next to the 3>&-, but I figure why not just limit its scope as much as possible.

我不确定直接使用文件描述符3和4的频率有多高——我认为大多数时候程序使用返回当前未使用的文件描述符的系统调用，但有时代码直接写入文件描述符3，我猜(我可以想象一个程序检查一个文件描述符，看看它是否打开，如果打开就使用它，如果没有打开则相应的行为不同)。因此，后者可能是最好记住并用于通用情况。

基于@brian-s-wilson的回答;这个bash helper函数:

pipestatus() {
  local S=("${PIPESTATUS[@]}")

  if test -n "$*"
  then test "$*" = "${S[*]}"
  else ! [[ "${S[@]}" =~ [^0\ ] ]]
  fi
}

使用:

1: get_bad_things必须成功，但它不应该产生输出;但我们希望看到它确实产生的输出

get_bad_things | grep '^'
pipeinfo 0 1 || return

2:所有管道必须成功

thing | something -q | thingy
pipeinfo || return

在bash之外，您可以执行以下操作:

bash -o pipefail  -c "command1 | tee output"

这很有用，例如在ninja脚本中，shell被期望为/bin/sh。

使用外部命令有时可能比深入研究bash的细节更简单、更清晰。管道，来自最小的进程脚本语言execline，以第二个命令*的返回代码退出，就像sh管道一样，但与sh不同的是，它允许反转管道的方向，以便我们可以捕获生产者进程的返回代码(以下都是在sh命令行上，但安装了execline):

$ # using the full execline grammar with the execlineb parser:
$ execlineb -c 'pipeline { echo "hello world" } tee out.txt'
hello world
$ cat out.txt
hello world

$ # for these simple examples, one can forego the parser and just use "" as a separator
$ # traditional order
$ pipeline echo "hello world" "" tee out.txt 
hello world

$ # "write" order (second command writes rather than reads)
$ pipeline -w tee out.txt "" echo "hello world"
hello world

$ # pipeline execs into the second command, so that's the RC we get
$ pipeline -w tee out.txt "" false; echo $?
1

$ pipeline -w tee out.txt "" true; echo $?
0

$ # output and exit status
$ pipeline -w tee out.txt "" sh -c "echo 'hello world'; exit 42"; echo "RC: $?"
hello world
RC: 42
$ cat out.txt
hello world

使用管道与原生bash管道的区别与答案#43972501中使用的bash进程替换相同。

*实际上管道不退出，除非有一个错误。它执行到第二个命令中，所以是第二个命令执行返回。

在普通bash中最简单的方法是使用进程替换而不是管道。有几个不同之处，但它们可能对你的用例不太重要:

当运行管道时，bash等待所有进程完成。 向bash发送Ctrl-C使其杀死管道的所有进程，而不仅仅是主要进程。 pipefail选项和PIPESTATUS变量与进程替换无关。 可能更

使用进程替换，bash只是启动进程，然后忘记它，它甚至在作业中都不可见。

除了上面提到的差异，消费者< <(生产者)和生产者|消费者本质上是相同的。

如果想要转换哪个进程是“主”进程，只需将命令和替换方向转换为生产者> >(消费者)。在你的情况下:

command > >(tee out.txt)

例子:

$ { echo "hello world"; false; } > >(tee out.txt)
hello world
$ echo $?
1
$ cat out.txt
hello world

$ echo "hello world" > >(tee out.txt)
hello world
$ echo $?
0
$ cat out.txt
hello world

正如我所说，它与管道表达式有不同之处。进程可能永远不会停止运行，除非它对管道关闭很敏感。特别是，它可能会不断向您的标准输出写入内容，这可能会令人困惑。

(command | tee out.txt; exit ${PIPESTATUS[0]})

与@cODAR的回答不同，它返回第一个命令的原始退出码，不仅成功为0，失败为127。但是正如@Chaoran指出的，你可以直接调用${PIPESTATUS[0]}。但重要的是，所有的都放在括号里。

为什么不使用stderr?像这样:

(
     # Our long-running process that exits abnormally
    ( for i in {1..100} ; do echo ploop ; sleep 0.5 ; done ; exit 5 )
    echo $? 1>&2 # We pass the exit status of our long-running process to stderr (fd 2).
) | tee ploop.out

所以ploop。Out接收标准输出。Stderr接收长时间运行的进程的退出状态。这样做的好处是完全与posix兼容。

(好吧，除了示例长时间运行的进程中的range表达式，但这并不真正相关。)

这是它的样子:

...
ploop
ploop
ploop
ploop
ploop
ploop
ploop
ploop
ploop
ploop
5

请注意，返回代码5不会输出到文件plop .out。