[Top][All Lists]

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

Re: tee logs no output if stdout is closed

From: Eric Blake
Subject: Re: tee logs no output if stdout is closed
Date: Mon, 01 Sep 2008 18:57:52 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080708 Thunderbird/ Mnenhy/

Hash: SHA1

According to Bruno Haible on 8/31/2008 9:39 AM:
> Right. close_stdout and more generally close_stream should be changed to
> handle an EPIPE failure. An EPIPE errno value means that the kernel is telling
> the program "This pipe/socket has no readers any more. You can stop writing
> to it." But in close_stream we are already stopping the output to this
> pipe/socket. There's no point in signalling an error about this situation.
> Also, if the reader process terminated only a moment later, the fflush and
> fclose would succeed, and the output would land in the kernel's pipe buffer
> and be discarded at that place.

Interesting arguments.  I'm still not 100% sure that POSIX allows or
forbids this, but I spent some time rereading
 Writes can only fail with EPIPE when SIGPIPE is ignored; if SIGPIPE is
not ignored, then the default handler would have already exited prior to
any EPIPE.  The subsection "Consequences of Errors" states that "utilities
may terminate prematurely if they encounter ... difficulties ... writing
files".  It is that use of "may" instead of "shall" that makes it sound
like it is still reasonable to ignore EPIPE rather than declaring it a
write failure; and provided that no message is printed to stderr and exit
status is not affected, then it looks like you are correct - a compliant
app can safely ignore EPIPE errors if it happened to inherit an ignored

One other argument in favor of Bruno's proposal:  for most write errors,
ignoring the error loses information (for example, discarding ENOSPC is
harmful, because the user may need to know when the disk is full).  But
for EPIPE, the user can always ensure that SIGPIPE is not ignored, and
thus that non-zero exit status will be provided (in other words, EPIPE is
an ignorable error because the user always has the option to avoid it in
the first place).

So, if Jim and/or Paul agrees, I'm inclined to agree with your gnulib
patch to close_stream, to silently ignore EPIPE rather than declare it a
write failure.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

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