Re: gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe

[Eric Blake]

echo "$handledmodules" | LC_ALL=C join -v 2 - "$tmp"/queued-modules

> 1) The 'join' command (or 'join --nocheck-order' in coreutils 6.11 or newer)
>    apparently closes its standard input and exits when the contents of the
>    second file (small enough or even empty) allows to determine the complete
>    'join' output - without having read all of its standard input.

Closing stdin on exit is expected by POSIX.  What's more, if stdin is
seekable, it must be reset back to the next position that was not
consumed by join.  But in this case, stdin is a pipe, so the state of
the pipe is explicitly called out as unspecified by POSIX, so it is
neither required to be fully consumed, nor to avoid losing data that
was buffered but not consumed by join.

> 
> 2) The kernel then transforms the pipe into a pipe with no readers.

Correct - if join finishes prior to echo, this is expected.

> 
> 3) The 'echo' command, when writing to a pipe with no readers, gets a SIGPIPE.

Yes.  But it depends on whether the shell is trapping/ignoring SIGPIPE
before this is detectable as a write error instead of an abrupt exit.

> 
> 4) The 'echo' command or its parent shell prints an error message on stderr.

Yes, echo (and all POSIX utilities) are required to print an error message
to stderr if exiting normally with non-zero status.  And if SIGPIPE is
being ignored, then echo must exit normally with non-zero status
(if SIGPIPE is not being ignored, then the exit is due to a signal, so
nothing need be printed).

> 
> Are these 4 behaviours all correct (POSIX compliant and to be expected)?
> If not, which one is incorrect/buggy?

It seems like they are all expected, so you should either change
gnulib-tool to not ignore SIGPIPE before using echo, or you should
change it to silence stderr when it is known that a piped stdout
might be closed early.

-- 
Eric Blake