为何两个Bash命令行为不同？Bash 3.2.57条件判断异常排查

我有一段Bash脚本，原写法如下：

if ! (colima status 2>&1 | grep -Fqe 'colima is running'); then
    colima start
fi

当colima实际运行时，该脚本仍会错误执行colima start；但改为以下写法后行为符合预期：

colima status 2>&1 | grep -Fqe 'colima is running' || colima start

我原本认为两种写法逻辑等价，想知道差异原因。当前脚本固定使用Bash 3.2.57，已开启set -xeuo pipefail。经排查发现，grep -Fqe会提前关闭管道触发SIGPIPE，导致其返回值为141（即使匹配到内容），但||写法却不受此影响。我需要理解该问题，因为多处场景要用到if !管道的模式。

colima status的输出示例：

time="2024-10-29T21:25:22-04:00" level=info msg="colima is running using macOS Virtualization.Framework"
time="2024-10-29T21:25:22-04:00" level=info msg="arch: x86_64"
time="2024-10-29T21:25:22-04:00" level=info msg="runtime: docker"

原因分析 #

1. pipefail与子shell的组合坑 #

你开启了set -o pipefail，这个选项会让管道的退出状态等于管道中最后一个非零退出的命令的状态。但在if ! (...)的写法里，括号会创建一个子shell，管道的状态会被完整传递：

• grep -q匹配到内容后立刻退出，关闭管道的写端。此时colima status还在输出，试图往关闭的管道写数据，触发SIGPIPE信号，退出码变成141。
• 因为pipefail，整个管道的退出码取colima status的141，而不是grep的0。!取反后结果为真，所以错误执行了colima start。

2. 直接管道+||的特殊处理 #

在||的写法中，Bash 3.2对pipefail的处理有区别：当管道的最后一个命令（这里是grep）成功退出（返回0），即使前面的命令（colima status）被SIGPIPE终止，管道整体的退出码依然是0。因此||后面的colima start不会触发，行为符合预期。

3. SIGPIPE退出码141的本质 #

grep -q的特性就是匹配到内容后立即终止，这会导致上游命令的管道写操作失败，触发SIGPIPE。退出码141是128+13（13是SIGPIPE的信号编号），这个码在子shell的管道中会被pipefail放大，成为整个管道的状态；但在直接管道的场景下，Bash会优先以最后一个成功命令的状态为准。

修复if !管道模式的方案 #

如果要保留if !的写法，可以用以下两种方式规避：

• 限制上游命令的输出，让它在grep退出后立刻停止：

if ! (colima status 2>&1 | head -n1 | grep -Fqe 'colima is running'); then
    colima start
fi

• 在子shell内临时关闭pipefail（仅影响当前管道，不破坏全局设置）：

if ! (set +o pipefail; colima status 2>&1 | grep -Fqe 'colima is running'); then
    colima start
fi

内容的提问来源于stack exchange，提问作者Camden Narzt