Hi Chet, Thanks for the info!
-Kye On 12/15/25 9:34 PM, Chet Ramey wrote:
On 12/13/25 7:53 AM, Kye Hunter wrote:Bash Version: 5.3 Patch Level: 8 Release Status: release Description:To start, I'm not totally sure if this is a bug with bash or with wc, as wc is the only program I have noticed this behavior in, but this seems like a good place to start.It's neither. It's not a bug at all, in fact. You correctly identify the issue:The inconsistent behavior makes this seem like a race, perhaps, in the script below, head is trying to close the pipe before wc finishes writing to it, causing it to return the error.But it doesn't have anything to do with bash. Consider the following sequence (at this point, bash is not in the picture; it's waiting for its children to terminate): wc writes the first line (of 7) to stdout, a pipe head reads the first line from the pipe head writes the single line to its stdout head exits with status 0 wc writes the second line to stdout wc receives SIGPIPE, a fatal signal, and exits as a result after which bash collects head's termination status (0)bash collects wc's termination status and converts it to 141 (128 + SIGPIPE)pipefail is set, so bash sets $? to 141This is just how pipes work. Writing on a pipe with no reader, and exiting due to the resultant SIGPIPE, is common and expected. You would never havenoticed if you hadn't enabled `pipefail'.
-- Kye E. Hunter PGP: 6859 E2DE D598 49EA 9319 10CD DEF2 BA03 A6BE 3062 --
OpenPGP_0xDEF2BA03A6BE3062.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
