shell-pipeline-exit-code-masking
Solution written to ~/shell-pipeline-exit-code-masking.md.
Root cause: In cmd 2>&1 | head -3; echo rc=$?, the pipeline is a single shell command, so $? is head's exit status (always 0 when it reads a line). The program under test leaves no trace in $?. This masks fatal exits (zerolog FTL -> os.Exit(1)) and crashing servers.
Exact fix (preferred):
cmd > /tmp/o 2>&1
rc=$?
Alternatives: ${PIPESTATUS[0]} (read immediately), or set -o pipefail.
Verified empirically:
- Buggy pattern: fatal binary exiting 1 reported rc=0.
- File redirect: rc=1 ✅
- PIPESTATUS[0]: rc=1 ✅
- pipefail: rc=1 ✅
Important caveat I caught and documented: pipefail/PIPESTATUS can report 141 (SIGPIPE) for a healthy exit-0 program when head closes the pipe early — verified with a noisy program (PIPESTATUS=(141 0)). That's why file redirection is the recommended probe: it runs the program to completion and reports its real status, with no pipeline and no SIGPIPE.
# Evidence - Problem class: shell-pipeline-exit-code-masking - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T00:18:51.401Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Reading $? after a pipeline reports the LAST command (head/tail), not the program under test. A fatal-exit binary (zerolog FTL -> os.Exit(1)) looked like rc=0 because the probe was `canopyd bogussubxyz 2>&1 | head -3; echo rc=$?`, and the same mistake makes a crashing server look healthy. Fix: redirect to a file (`cmd > /tmp/o 2>&1; echo rc=$?`) or read PIPESTATUS[0] with `set -o pipefail`. Symptom pattern: every measured exit code is 0 no matter what the binary does.", "environment": "", "language": "bash", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "shell-pipeline-exit-code-masking", "provider": "openrouter", "solved_at": "2026-09-17T00:18:51.401Z", "version": ""}Solution written to ~/shell-pipeline-exit-code-masking.md.
Root cause: In cmd 2>&1 | head -3; echo rc=$?, the pipeline is a single shell command, so $? is head's exit status (always 0 when it reads a line). The program under test leaves no trace in $?. This masks fatal exits (zerolog FTL -> os.Exit(1)) and crashing servers.
Exact fix (preferred):
cmd > /tmp/o 2>&1
rc=$?
Alternatives: ${PIPESTATUS[0]} (read immediately), or set -o pipefail.
Verified empirically:
- Buggy pattern: fatal binary exiting 1 reported rc=0.
- File redirect: rc=1 ✅
- PIPESTATUS[0]: rc=1 ✅
- pipefail: rc=1 ✅
Important caveat I caught and documented: pipefail/PIPESTATUS can report 141 (SIGPIPE) for a healthy exit-0 program when head closes the pipe early — verified with a noisy program (PIPESTATUS=(141 0)). That's why file redirection is the recommended probe: it runs the program to completion and reports its real status, with no pipeline and no SIGPIPE.
# Evidence - Problem class: shell-pipeline-exit-code-masking - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T00:18:51.401Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Reading $? after a pipeline reports the LAST command (head/tail), not the program under test. A fatal-exit binary (zerolog FTL -> os.Exit(1)) looked like rc=0 because the probe was `canopyd bogussubxyz 2>&1 | head -3; echo rc=$?`, and the same mistake makes a crashing server look healthy. Fix: redirect to a file (`cmd > /tmp/o 2>&1; echo rc=$?`) or read PIPESTATUS[0] with `set -o pipefail`. Symptom pattern: every measured exit code is 0 no matter what the binary does.", "environment": "", "language": "bash", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "shell-pipeline-exit-code-masking", "provider": "openrouter", "solved_at": "2026-09-17T00:18:51.401Z", "version": ""}