Bash and pipefail – Non deterministic conditionals
Comments on “Bash and pipefail – Non deterministic conditionals”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
A debugging write-up explains why conditions like long-output-cmd | grep -q magic fail intermittently in scripts using set -eo pipefail. Once grep finds a match it exits, and the still-writing producer is killed by SIGPIPE (status 141), which pipefail then reports. Small outputs fit in the 64 KB pipe buffer and never fail; larger ones fail more often under CPU load. The author's tests on one machine show head -1, sed 1q and grep -m1 behave the same. Fixes: read to EOF, capture output first, or tolerate 141.
Why it ranked
No. 10 of 111 with a score of 0.68. The panel rated it highest on technical depth (0.93) and new information (0.92), lowest on significance (0.46). Placed No. 10, No. 13 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Clear, well-evidenced debugging write-up of a bash pipefail/SIGPIPE race with reproducible commands and measurements; narrow audience, practical for shell script authors, no new-story overlap.
- AI judgeJudge 3gpt-5.6-luna
- A well-supported, reproducible Bash pipeline explanation with experiments, race-condition analysis, and practical fixes. It is highly useful to shell and systems programmers, though its significance is mainly niche rather than field-wide.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.68total under rubric v2.3
- Significance0.46
- Reader interest0.77
- Audience breadth0.56
- Practical relevance0.79
- Substantiated0.91
- Technical depth0.93
- New information0.92
- Counts against: Promotional0.02
- Counts against: Overclaim0.12
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.49 | 0.35 | 0.55 | 0.46 | 0.20 | +0.24 | +0.111 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.62 | 0.80 | 0.90 | 0.77 | 0.28 | +0.26 | +0.201 |
| Audience breadthHow many people who build technology does it concern? | 0.64 | 0.60 | 0.45 | 0.56 | 0.19 | +0.13 | +0.073 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.77 | 0.80 | 0.80 | 0.79 | 0.04 | +0.22 | +0.173 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.97 | 0.85 | 0.90 | 0.91 | 0.12 | +0.05 | +0.045 |
| Technical depthHow technically substantive is it? | 1.00 | 0.90 | 0.88 | 0.93 | 0.12 | +0.05 | +0.046 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.89 | 0.90 | 0.98 | 0.92 | 0.09 | +0.05 | +0.046 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.04 | 0.02 | 0.01 | 0.02 | 0.03 | −0.19 | −0.004 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.18 | 0.10 | 0.08 | 0.12 | 0.10 | −0.11 | −0.013 |
| Sum of contributions | +0.679 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.679 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-31/10/"><img src="https://rubric.hrih.si/badge/2026-10-31/10.svg" alt="Ranked #10 on Rubric, 31 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 8 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenQuote
Under pipefail, a pipeline's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully, according to man bash.
The article gives no link or citation for it.
The article says “If pipefail is enabled, the pipeline's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully”
The source says No source to compare with.
No source givenQuote
grep -q exits immediately with zero status if any match is found, even if an error was detected, according to man grep.
The article gives no link or citation for it.
The article says “Exit immediately with zero status if any match is found, even if an error was detected”
The source says No source to compare with.
No source givenCausal conclusion
Writing to a pipe with no reader raises SIGPIPE, whose default action kills the process, so bash records exit status 128 + 13 = 141 for the killed upstream command.
The article gives no link or citation for it.
The article says “writing to a pipe with no reader raises the SIGPIPE signal, and SIGPIPE's default action is to kill the process. So long-output-cmd is not reporting an error it noticed”
The source says No source to compare with.
No source givenNumber
A Linux pipe holds 65536 bytes by default, so seq 1 1000 (3.9 KB of output) completes into the buffer and does not fail.
The article gives no link or citation for it.
The article says “a Linux pipe holds 65536 bytes by default, so the producer writes everything into the buffer and exits 0 before grep is even relevant”
The source says No source to compare with.
No source givenNumber
With pipefail, seq 1 13000 | grep -q '^1$' returned non-zero in 4 of 40 runs, and seq 1 50000 in 20 of 20 runs.
The article gives no link or citation for it.
The article says “$ (set -o pipefail; seq 1 13000 | grep -q '^1$') # 4 non-zero in 40 runs”
The source says No source to compare with.
No source givenBenchmark result
Under CPU load (14 busy loops on 14 cores), the failure rate for seq 1 13000 | grep -q rose from 4/40 idle to 29/40.
The article gives no link or citation for it.
The article says “seq 1 13000 66 KB 4/40 29/40”
The source says No source to compare with.
No source givenGeneralization
Any downstream command that stops reading before EOF (head -1, sed 1q, awk exit, grep -m1, read) can kill a slow upstream producer under pipefail; this is not specific to grep -q.
The article gives no link or citation for it.
The article says “Nothing in this is specific to grep -q. The condition is about shape: any downstream command that stops reading before EOF can kill a slow upstream producer”
The source says No source to compare with.
No source givenCausal conclusion
Fixes that avoid the bug include dropping -q, capturing output in a variable first, or tolerating exit status 141; using grep -m1 still fails 20/20 runs.
The article gives no link or citation for it.
The article says “long-output-cmd | grep -m1 'magic' >/dev/null # 20/20 still broken”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 1 pts, not on front page
Recorded for context only, checked 31 Oct 2026, 05:46 UTC. It played no part in the ranking.