Linux Shell 脚本退出码不对怎么查：set -e、pipefail 与管道末项

凌晨的备份任务在日志里留下了明显的错误行，监控却收到“成功”。排查后发现，脚本把一段失败的日志筛选命令接到了 head 后面，而 Bash 默认只把管道最后一个命令的退出码交给调用方。Shell 里“命令跑完了”和“任务成功了”不是一回事。

先还原一个“返回 0”的故障现场

假设脚本负责检查备份日志里有没有失败标记：

#!/usr/bin/env bash
set -e

grep -q 'backup failed' /var/log/backup.log | head -n 1
echo 'backup check passed'

这里有两个问题。第一，grep -q 找到字符串时返回 0，没找到时返回 1；第二，管道整体默认使用最后一个命令的状态，而 head 通常正常结束并返回 0。于是前面的结果没有成为脚本结果，最后的 echo 还可能再次把状态改成 0。

先别急着把所有命令前面都加上 set -e。需要先回答：这个脚本要判断的是“有没有匹配行”，还是“日志读取过程是否出错”？两者不是同一个条件。

把显式退出码收口当成一种小型架构模式

这类脚本最稳的做法，是把每段命令的结果当成数据处理：先明确哪个状态代表失败，再在脚本出口统一返回。它适合备份、发布、巡检和 CI 检查这类“上游要知道成败”的任务；不适合把所有非零状态都粗暴视为故障的探索性命令串。

第一层：让管道整体看到前置失败

如果管道中的任一命令失败都应该让这段任务失败，可以打开 pipefail：

set -o pipefail

if grep -q 'backup failed' /var/log/backup.log | head -n 1; then
  echo '发现失败标记'
  exit 2
fi

打开后，管道会在相关命令失败时返回非零状态。这里仍然要区分“没有匹配”与“文件无法读取”：如果业务只是查找字符串，未匹配可能是正常结果；如果日志文件不存在，才是脚本故障。最好的判断通常不是把一条复杂管道塞进 set -e，而是拆成可命名的检查。

第二层：需要多个状态时读取 PIPESTATUS

Bash 会把刚刚执行的管道中每个命令的状态放在 PIPESTATUS 数组里。它只能在下一条命令覆盖之前读取，所以要马上复制：

set -o pipefail

grep -q 'backup failed' /var/log/backup.log | head -n 1
pipeline_status=("${PIPESTATUS[@]}")

grep_status="${pipeline_status[0]}"
head_status="${pipeline_status[1]}"
if [ "$head_status" -ne 0 ]; then
  echo '读取管道末项失败' >&2
  exit 3
fi
if [ "$grep_status" -eq 0 ]; then
  echo '发现失败标记' >&2
  exit 2
fi
if [ "$grep_status" -ne 1 ]; then
  echo 'grep 执行异常' >&2
  exit 4
fi
echo '未发现失败标记'

上面把 grep 的 1 当作“没有匹配”，把其他非零值当作读取或执行问题。实际项目中也可以不用管道，直接让 grep 写入变量或临时文件，代码会更容易被不熟悉 Bash 的同事维护。

set -e 为什么不是万能的失败开关

set -e 的意图是：某些简单命令失败时让 Shell 退出。但 Shell 必须允许失败命令出现在条件判断里，否则下面这种正常分支无法工作：

set -e

if grep -q 'ready' status.txt; then
  echo '服务已就绪'
else
  echo '服务尚未就绪'
fi

grep 没找到文本时返回 1，这在 if 条件里是分支结果，不应直接终止脚本。类似的豁免还会出现在 while、until、! 和某些逻辑连接符场景。不同 Bash 版本和嵌套写法还会让阅读者更难凭直觉判断。

生产脚本可以使用：

set -Eeuo pipefail
trap 'printf "line=%s status=%s" "$LINENO" "$?" >&2' ERR

但这只是提高默认保护，不能省掉关键步骤的显式检查。尤其是有业务语义的非零状态，要放进 if 或变量判断里写清楚，别让调用者猜。

三个常见反例：看起来严谨，结果仍会漂移

• 只加 set -e：管道前项、条件命令和被覆盖的状态仍可能漏掉；它解决不了“哪个结果算成功”的定义问题。
• 在读取状态前打印日志：echo、命令替换和函数调用都可能让原始状态难以追踪，PIPESTATUS 必须紧跟管道保存。
• 结尾无条件返回 0：这会把前面的失败重新包装成成功。只有所有必要检查完成后，才应该返回 0。

在 CI 和定时任务里怎样验收

不要只在交互式终端里运行一次。至少准备三组输入：日志没有失败标记、日志包含失败标记、日志路径不可读。每组都记录标准输出、标准错误和最终退出码：

bash check-backup.sh >out.log 2>err.log
status=$?
printf 'status=%s' "$status"

约定返回值后，CI 可以按数值做清晰处理，例如 0 表示检查通过，2 表示发现业务失败标记，3 表示管道末项故障，4 表示日志读取异常。定时任务也应把非零返回交给监控，而不是在脚本末尾用一条无条件成功命令覆盖它。

常见问题

pipefail 会不会让所有脚本都更安全？

它只改变管道整体的退出判断，不会替你定义业务成功条件。搜索命令“没找到”是否算失败，仍要由脚本明确处理。

PIPESTATUS 能不能在下一条命令之后再读？

不建议。下一条管道或其他命令可能覆盖它，应该立即复制成自己的数组或变量。

set -e 和显式 if 判断要二选一吗？

不用。可以用 set -Eeuo pipefail 提供默认保护，再对有业务含义的命令使用显式判断，两者职责不同。

脚本最后打印成功信息后为什么返回 0？

通常是最后一条命令成功，或者脚本显式写了 exit 0。检查每个关键阶段的状态，并确保失败分支先返回，不要让结尾输出覆盖结果。

把“命令结束”改成“结果可验收”

Shell 管道短小方便，却把多个进程的状态压在一条命令线上。脚本一旦被 CI、cron 或监控调用，就应该主动拆出成功条件：用 pipefail 处理整体失败，用 PIPESTATUS 保存细节，用显式分支区分“没有匹配”和“读取异常”。这几行判断比一次偶发的误报更便宜，也更容易在下一次故障时复盘。