Bash pipefail 配合 head 取首行后退出 141

Bash 脚本开启 set -e 和 pipefail 后，用 head -n 1 取输出首行，终端已经显示了想要的内容，脚本却以 141 退出。输入较小时又可能正常结束，让问题看起来像是偶发错误。

在 Linux 上，这常见于下游读到首行后提前退出，上游仍在向管道写数据。所有读端关闭后，继续写入会触发 SIGPIPE；Bash 对被信号 13 终止的命令报告状态 128 + 13，也就是 141。pipefail 会让上游的非零状态影响整条管道。

仅凭 141 不能断定原因，程序也可能主动返回相同数值。应先看各段命令的状态，再决定是否改变消费方式。下文针对 Bash 与 Linux，不把这些数组和状态检查直接套到 /bin/sh。

先保留每一段的状态

在独立测试脚本中，用不涉及业务写入的有限数据检查这种结构。下面要求系统有 seq 和 head：

#!/usr/bin/env bash
set +e
set -o pipefail

seq 1 100000 | head -n 1
stages=("${PIPESTATUS[@]}")
printf 'producer=%s consumer=%s\n' "${stages[0]}" "${stages[1]}"

这里暂时不启用 errexit，否则管道非零时可能在保存数组前就结束脚本。PIPESTATUS 必须紧跟管道保存；先运行 echo、printf 或另一条命令，都可能覆盖要观察的状态。

如果生产数据的命令为 141，而 head 为 0，与“消费者正常提前结束、生产者随后遇到断开的管道”一致。若状态出现在其他位置，或同时有实际读写错误，应按那一段的错误继续判断，不能统一当作可忽略的 SIGPIPE。

这个示例不保证每次都出现 141。上游可能在下游关闭之前已把全部数据写完；管道缓冲、输出量和执行时序都会影响结果。不要用某个固定行数划定安全范围，也不要因为把输入减小后不再失败，就认定业务数据已经修复。

有限输入只需显示首行时，让消费者读到结尾

如果上游本来就应完整执行，输入保证会结束，只是不想显示其余行，可以让 sed 只打印首行，同时继续读取后面的输入：

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

seq 1 100000 | sed -n '1p'
printf 'pipeline completed\n'

-n 关闭默认打印，1p 只打印第一行。这里没有退出命令，sed 仍会读到输入结束，因此不会因“已经拿到首行”主动关掉读端。实际脚本应保留原生产命令，只替换这段消费者；同时确认该命令完整运行符合业务要求。

不要把它改成 sed -n '1p;1q'，也不要换成打印后立即 exit 的 awk，再期待避免同一问题。这些写法仍然提前退出。增加后续的 tee 也不能让已经退出的前一段继续接收输入。

这项调整会改变结束时机：即使首行很快出现，脚本仍要等待上游完整结束，还会读取并丢弃剩余内容。后续网络读取、计算或业务副作用仍会发生。它适合有限输入的完整处理，不适合用来停止无限日志流，也不是减少上游工作量的办法。

真正要提前停止时，先定义取消规则

若需求就是取得第一条后停止昂贵任务，应优先使用生产程序自己提供的条数限制或取消接口。这样生产者可以按自己的协议结束，不必让一个不知情的生产者持续写向已关闭的管道。

必须用提前关闭读端来取消时，要明确哪些生产者、哪些状态可以被视作预期取消，并分别检查其他阶段的失败。不要给整条业务管道无条件加 || true，也不要全局关闭 pipefail：这会同时掩盖真正的解析、读取和写入错误。通用脚本无法仅凭 141 判断本次业务结果是否完整。

检查成功路径，也检查真实错误能否留下

修改后，在隔离测试中覆盖空输入、单行输入和多行有限输入，确认输出仍符合约定。空输入没有首行，并不自动意味着管道执行失败；若业务要求至少一条结果，应另行验证这个条件。

还应让生产者在可控测试中返回真实错误，确认脚本不会继续报告成功。sed 正常读到结束不表示上游成功，保留 pipefail 才能继续暴露其非零状态。

保存原脚本再修改。若完整消费带来的耗时或副作用不符合预期，恢复脚本并改用生产者的限制接口；已经执行的前缀操作不会因回退文件而撤销，重跑之前仍需核对业务进度。