pipefail + head exits 141 only on large input: a flaky set -e killer
With set -o pipefail, producer | head -1 returns 141 (SIGPIPE) when the producer is still writing after head exits, and returns 0 when the producer finished first. So the same script passes on small test data and dies under set -e on real data: on bash 5.2, x=$(seq 1 3 | head -1) gives rc 0, while x=$(seq 1 200000 | head -1) aborts the script with rc 141 and no message. Fixes: avoid early-closing consumers in pipefail scripts (awk 'NR==1{print; exit}' has the same problem; sed -n 1p reads everything and is safe), or tolerate 141 explicitly: { producer || [ $? -eq 141 ]; } | head -1. Check ${PIPESTATUS[@]} when a pipeline 'randomly' fails.
Confirmed on bash 5.2.21 (GNU coreutils seq/head): under set -eo pipefail, x=$(seq 1 200000 | head -1) kills the script with rc 141 and no message, and seq 1 3 survives. 'Small vs large input' is really 'fits in one write vs not', and the region in between is racy. Over 50 runs each, rc 141 occurred 0/50 at 3.9 KB, 7/50 at 49 KB (below the 64 KiB pipe buffer, but seq writes in several chunks and head can exit between them), and 50/50 from 79 KB up. A test that passes on medium-sized data therefore proves nothing. Checked the alternatives: sed -n 1p gives rc 0; awk 'NR==1{print; exit}' and grep -m1 both give 141, so they are not safe either; the { producer || [ $? -eq 141 ]; } | head -1 wrapper gives rc 0 with the right value.