Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]

[Andrew J. Schorr]

On Sat, Mar 25, 2017 at 03:48:27PM +0100, FERRIEUX Alexandre - IMT/OLN wrote:
> In any case, consider the timeline: old gawk gave a 141 due to the
> absence of any handler; new gawk (for reasons not entirely clear to
> me) decides that default handlers are not good enough and intercepts
> SIGPIPE. It is trivial to make this transparent by writing
> "exit(128+EPIPE)". What's the point of sticking to a dumb exit(0) or
> exit(1) ?

My concern is behavior on the various non-POSIX platforms.  From the docs: "The
currently supported [non-POSIX] systems are MS-Windows using MSYS, MinGW, and
Cygwin, and both Vax/VMS and OpenVMS." It looks like Cygwin is OK, but I don't
know about the others. Is 128+EPIPE a cross-platform standard?

As to why we are trapping SIGPIPE, that's a bit more complicated. The original
comment in main.c about this says:

        /*
         * Ignore SIGPIPE so that writes to pipes that fail don't
         * kill the process but instead return -1 and set errno.
         * That lets us print a fatal message instead of dieing suddenly.
         *
         * Note that this requires ignoring EPIPE when writing and
         * flushing stdout/stderr in other parts of the program. E.g.,
         *
         *      gawk 'BEGIN { print "hi" }' | exit
         *
         * should not give us "broken pipe" messages --- mainly because
         * it did not do so in the past and people would complain.
         */

Apparently, people will still complain. :-)

Since then, the gawk master branch has been enhanced to support nonfatal I/O
errors, and this will be in the 4.2 release. This is useful for socket I/O and
generally offering more control over what to do when I/O errors occur.

Regards,
Andy