开启set -e时，如何在Bash中捕获退出码而非终止脚本？

确实，在全局启用set -e -u -E -o pipefail的严格模式下，要优雅捕获单个命令（尤其是多行管道命令）的退出码还不触发脚本终止，那些你列出的写法要么啰嗦、要么有兼容性问题，要么意图表达不清晰。这里有几个更实用的方案：

1. 极简兼容式（首推） #

这个写法在你列出的写法3基础上优化了意图表达，而且完全兼容pipefail：

exitCode=0
COMMAND_WITH_LONG_ARGS \
| PIPE_CMD1 \
| PIPE_CMD2 || exitCode=$?

• 优势：视觉上完全保留了管道命令的连贯性，不会打断代码阅读流；pipefail生效时，能正确捕获管道中第一个非零的退出码；不需要临时修改全局的set -e设置，跨脚本迁移时绝对安全。

2. 子shell单表达式捕获 #

如果你不想单独初始化exitCode变量，可以用子shell临时关闭set -e，直接把退出码赋值给变量：

exitCode=$(set +e; COMMAND_WITH_LONG_ARGS \
| PIPE_CMD1 \
| PIPE_CMD2; echo $?)

• 优势：一行完成捕获（多行只是为了拆分长管道）；子shell里的set +e不会影响全局脚本的严格模式，迁移时没后顾之忧；同样完美兼容pipefail。

3. 紧凑条件判断写法 #

针对你觉得写法2太冗长的问题，可以简化成更紧凑的条件表达式：

COMMAND_WITH_LONG_ARGS \
| PIPE_CMD1 \
| PIPE_CMD2 && exitCode=0 || exitCode=$?

⚠️ 注意：这个写法和你列出的写法4类似，但一定要保证逻辑顺序——只有命令成功时才赋值0，失败时才捕获实际退出码。如果命令成功后&&后面的语句意外出错（比如exitCode=0这种操作几乎不可能出错，但还是要提一下），会错误捕获后续语句的退出码，所以只在你确定命令成功后无额外风险时使用。

为什么这些写法更靠谱？ #

• 避开了临时修改全局set -e的坑（写法1的迁移失效问题）；
• 砍掉了冗余的if/else结构（写法2的冗长问题）；
• 完全兼容pipefail（写法5的兼容性问题）；
• 不需要在每个脚本里重复定义函数（写法6的重复代码问题）；
• 视觉上清晰传达了“捕获这个命令/管道退出码”的意图，不会让后续维护的人困惑。

另外，如果你经常需要这个操作，还可以把它封装成一个公共函数放在单独的脚本里（比如bash_utils.sh），然后在需要的脚本里source一下就行，不用重复写：

# bash_utils.sh
capture_exit_code() {
    local exit_code=0
    "$@" || exit_code=$?
    return $exit_code
}

使用时：

source bash_utils.sh
capture_exit_code COMMAND_WITH_LONG_ARGS \
| PIPE_CMD1 \
| PIPE_CMD2
exitCode=$?

这个方法既解决了重复代码的问题，又保持了调用时的简洁性。

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