bug-gnulib
[Top][All Lists]
Advanced

[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:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
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
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html#tag_01_11.
 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
SIGPIPE.

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
-----BEGIN PGP SIGNATURE-----
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

iEYEARECAAYFAki8j5AACgkQ84KuGfSFAYAvXwCeLzA1qM6Zqp5mM5QqHkRmOcVF
hQwAn03Ko02DgtcFgKGWCf8YwbS7ykyH
=u9xO
-----END PGP SIGNATURE-----




reply via email to

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