Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > You can distinguish close_stream and close_stdout. close_stream is library >> > code, >> > close_stdout is not. What about a 'bool ignore_epipe' that influences the >> > behaviour of close_stdout? Whereas the library code that called >> > close_stream >> > has to check against EOF/EPIPE itself if it wants to. >> >> Indeed. This sounds workable, perhaps using a new >> close_stdout_ignore_epipe function. > > Here's a proposed patch. The function name 'close_stdout_set_ignore_EPIPE' > was chosen for consistency with the already existing function > 'close_stdout_set_file_name'. > > > 2008-10-04 Bruno Haible <[EMAIL PROTECTED]> > Jim Meyering <[EMAIL PROTECTED]> > > Add an option for ignoring EPIPE during close_stdout. > * lib/closeout.h: Include <stdbool.h>. > (close_stdout_set_ignore_EPIPE): New declaration. > * lib/closeout.c: Include <stdbool.h>. > (ignore_EPIPE): New variable. > (close_stdout_set_ignore_EPIPE): New function. > (close_stdout): Ignore EPIPE error if ignore_EPIPE is set. > * lib/close-stream.c (close_stream): Mention the possible EPIPE > failure. > * modules/closeout (Depends-on): Add stdbool. ... > +static bool ignore_EPIPE /* = false */; > + > +/* Specify whether an EPIPE error during the closing of stdout should be > + ignored (ignore = true) or signaled to the user through an error message > + (ignore = false).
Thanks for writing all that. The code looks fine. Let's not use "signaled" here. How about this in place of the above: /* Tell close_stdout whether to ignore an EPIPE error. The default (ignore = false) ensures that a close_stdout-induced write failure due to EPIPE evokes a diagnostic about the failure, along with a nonzero exit status. Use ignore = true to make close_stdout ignore any EPIPE error. > + This setting matters only if the SIGPIPE signal is ignored (i.e. its > + handler set to SIG_IGN) or blocked. Only particular programs need to > + temporarily ignore SIGPIPE. If SIGPIPE is ignored or blocked because > + it was ignored or blocked in the parent process when it created the > + child process, it usually is a bug in the parent process: It is bad > + practice to have SIGPIPE ignored or blocked while creating a child > + process. > + > + EPIPE occurs when writing to a pipe or socket that has no readers now, > + when SIGPIPE is ignored or blocked. > + > + The ignore = false setting is suitable for a scenario where it is normally > + guaranteed that the pipe writer terminates before the pipe reader. In > + this case, an EPIPE is an indication of a premature termination of the > + pipe reader and should be signaled. Best not to use "signaled" here. Perhaps "diagnosed" instead. > + > + The ignore = true setting is suitable for a scenario where you don't know s/is/may be/ Early reader termination may still deserve a diagnostic. Or it could be that POSIX requires the application to diagnose EPIPE, regardless ;-) > + ahead of time whether the pipe writer or the pipe reader will terminate > + first. In this case, an EPIPE is an indication that the pipe writer can > + stop doing useless write() calls; this is what close_stdout does anyway. > + EPIPE is part of the normal pipe/socket shutdown protocol in this case, > + and should not be signaled. */ s/signaled/diagnosed/ With those changes, you're welcome to commit. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
