https://tro3373.github.io/tags/sigpipe/ Recent content in sigpipe on tac lifelog https://tro3373.github.io/favicon.png https://tro3373.github.io/favicon.png Hugo ja Tue, 27 Oct 2026 13:39:45 +0900 https://tro3373.github.io/posts/2026/2026-10-27-bash-pipeline-exit-status-sigpipe/ Tue, 27 Oct 2026 13:39:45 +0900 https://tro3373.github.io/posts/2026/2026-10-27-bash-pipeline-exit-status-sigpipe/ <h2 id="結論">結論</h2> <ul> <li>パイプの終了コードは、既定では末尾のコマンドのもの。<code>set -o pipefail</code> を立てると、最後に非 0 で終わったコマンドのものになる</li> <li><code>||</code> と <code>if</code> はパイプ全体の終了コードを見る。<code>cmd | grep -v X || true</code> は cmd の失敗も 0 にし、<code>if cmd | grep -q X</code> は取得の失敗を「一致なし」と同じ偽にする</li> <li>読み手が終わった後に書き手が書くと、書き手は SIGPIPE で 141 になり、<code>pipefail</code> がそれを全体の終了コードにする。<code>| head</code>、<code>| grep -q</code>、stdin を読まない読み手で起き、出力が小さくても書く順番しだいで起きる</li> <li><code>mapfile &lt; &lt;(cmd)</code> はパイプではないので、cmd の失敗はどこにも残らない</li> <li>判定に使う出力は先に変数へ取り、here-string で渡す。fallback 付きのコマンドは、成功したときだけ stdout に出す</li> </ul> <p>以下は GNU bash 5.3.15 / GNU coreutils 9.11 / GNU grep 3.12 / Linux x86_64 で実測した。回数を書いたものはタイミングで決まるので、環境によって数字が変わる。</p> <h2 id="前提-パイプの終了コードはどのコマンドのものか">前提: パイプの終了コードはどのコマンドのものか</h2> <p><img alt="既定ではパイプの終了コードは右端のコマンドのもので、pipefail を立てると最後に非 0 で終わったコマンドのものになる" loading="lazy" src="https://tro3373.github.io/posts/2026/2026-10-27-bash-pipeline-exit-status-sigpipe/fig-status.webp"></p>