On 12/13/25 7:53 AM, Kye Hunter wrote:
Bash Version: 5.3 Patch Level: 8 Release Status: releaseDescription: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 141
This 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 have
noticed if you hadn't enabled `pipefail'.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
