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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
