set -o pipefail 搭配 grep -q：匹配到了，if 却返回 false
在脚本开头写 set -euo pipefail 后，把命令通过管道交给 grep -q，会踩到一个确定可复现的坑。
核心陷阱：同时开 set -o pipefail 并把命令管道给 grep -q。
set -o pipefail
if seq 1 10000000 | grep -q "^5$"; then echo "matched"; fi
预期输出 matched，实际不会。原因在于 grep -q 一旦找到 "5" 就立即退出，上游 seq 继续写，就会收到 SIGPIPE 而失败；因为开了 pipefail，管道中任一命令失败即视为整条失败，if 判定为 false——尽管确实匹配到了。
这不是真正的竞态，是确定可复现的；当上游耗时不固定时，会出现“多数时候正常、偶发失败”，很难查。单独运行匹配命令看起来没问题，放进脚本或 CI 里却偶发走 else 分支，往往就是这里。
解决办法
1）不设 pipefail。但它往往是有意设的，而且 pipefail 一旦设置会持续生效，可能来自脚本链上游。
2）先把输出存变量再匹配：
numbers="$(seq 1 10000000)"
if grep -q "^5$" <<< "$numbers"; then ... fi
本例低效，但“先物化结果再匹配”在很多场景是好选择。
3）用 awk 读完整个流：
if seq 1 10000000 | awk '$0 == 5 { found=1 } END { exit !found }'; then ... fi
4）用进程替换消除管道本身。bash 不把它当 pipeline，pipefail 不影响：
if grep -q "^5$" < <(seq 1 10000000); then ... fi
相关背景
- 每个脚本开头
set -euo pipefail：-e出错即退；-u读未定义变量即退（防$pth打错）；-o pipefail管道退出码取最右非零。 - 清理用单个
trap ... EXIT；trap不会被()、$()、管道子 shell 继承，子 shell 里要重新注册；多个 EXIT trap 只有最后一个生效。 set -e与trap ERR的交互复杂，有些场景set -e会先退出、ERR trap 不触发；strict 模式下更推荐在 EXIT trap 里判$?。- CI 中“永远不失败”的步骤：
cmd | tee log || true——没有pipefail时退出码是tee的（永远 0），再叠加|| true，双重掩盖失败。
参考：