Orien Daily
🔑 为什么 Shell 管道默认会“吞掉”前面的错误？ cat missing.txt | grep foo | wc -l 这种命令，Shell 默认只看最后一个命令的退出状态，也就是 wc -l。这意味着前面的 cat 就算已经报错，只要最后的 wc 正常结束，整条管道在很多脚本里仍然会被当成“成功”。build_cmd | tee build.log，tee 几乎总能成功，于是即使 build_cmd 已经失败，脚本还是继续往下跑。表面看日志也有输出，实际上流程已经坏了。这种 bug 最烦人的地方就在于它不炸，它只是悄悄给你一个假成功。set -o pipefail。它的意思是：只要管道里任意一个命令失败，整条管道就失败。这样脚本才更像你脑子里想的那样工作。再配合 set -euo pipefail，Shell 会更早暴露问题，而不是帮你偷偷兜底。这里的重点不是“语法技巧”，而是态度：不要让脚本假装没事，错了就该尽快暴露。pipefail 也不是无脑全开就完事。有些命令失败是正常控制流的一部分。最常见的是 grep 没找到内容时会返回 1，这不一定表示异常。如果你开了 pipefail，又把这种返回值当成真正错误，脚本就会过度敏感。所以关键不是迷信某个选项，而是明确区分“业务上允许的未命中”和“真正的执行失败”。🧪 false | true，在 Bash 默认设置下整条管道的退出状态是多少？打开 set -o pipefail 后又是多少？答案：默认是 0，因为只看最后一个 true；打开 pipefail 后是非 0，因为前面的 false 失败会让整条管道失败。 💡 grep 返回 1 往往表示“没找到”，不等于程序出错；而 pipefail 关心的是退出码，不会替你判断这个 1 在业务上是不是合理。
12:00 · Jul 30, 2026 · Thu
CS
