Re: SIGPIPE not properly reset with 'trap - PIPE'

[Chet Ramey]

Ralf Wildenhues wrote:
> Hello bug-bash readers,
> 
> I noticed the following bash bug when using gnulib-tool.  The script
> below outputs
> 
> foo: line 20: echo: write error: Broken pipe
> foo: line 21: echo: write error: Broken pipe
> 
> with bash 3.2.48(5)-release on GNU/Linux, whereas I think it should be
> silent.  Please note that the script assumes that GNU coreutils seq is
> installed.

This is the result of two much-requested changes to bash that appeared
in bash-3.2.

The first has to do with signals that cause the shell to terminate.  The
shell has to do a fair amount of cleanup work before it exits, especially
interactive shells -- job control, tty restoration, maybe saving the
history, and so on.  There were lots of complaints that the shell was
doing too much, and calling too many disallowed functions, in a signal
handler, so bash-3.2 changed to setting a `terminating signal received'
flag on signal receipt and handling the condition later.  SIGPIPE is
such a signal.  (There is also a way to tell bash to just shut up and
exit on a terminating signal, standards be damned.)

The second is that the echo builtin in bash-3.2 displays a message on
a write error, instead of letting the exit status communicate the error.
When the shell receives SIGPIPE and handles it without exiting, writes
to that pipe return -1/EPIPE, and the echo builtin reports the error.  In
earlier versions, you wouldn't have seen the message.

The fix is to add more checks for receipt of terminating signals and to
tell the shell to exit right away if executing an `output builtin' like
echo or printf when a terminating signal is caught.  It will be in
bash-4.0.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/