[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew J. Schorr
Subject: Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]
Date: Sat, 25 Mar 2017 11:13:40 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]