Re: tee logs no output if stdout is closed

[Paolo Bonzini]

Jim,

> Imagine a scenario in which the pipe reader is expected always to
> be reading, and so the pipe writer can expect that any write failure with
> errno==EPIPE indicates the reader has terminated unexpectedly.

If the writer should terminate first, the reader can still detect the
failure using SIGPIPE and/or SIGCHLD.  Since you say that you consider
ignoring the signal to be discouraged, these programs should not see
EPIPE anyway.  Yes, you also said:

> Some environments (mis-configured login/csh) have
> resulted in the default SIGPIPE handler being SIG_IGN.

... but there are so many other problems that could result from
misconfiguration, such as fd 0/1/2 not being open.  I don't think
programs that do not impact security should try to cater for this;
programs that do care about security, instead, are already armored
against misconfigured signals and everything else.  Furthermore, it's
not gnulib's purpose to do this currently, and even if there was a
"super-security" module, it would not make Bruno's proposal any less viable.


Replying to Bruno,

> If you want both scenarios - the "don't know which of the two terminates 
> first"
> and the "writer must terminate first" - to be supported by close_stream and
> close_stdout, IMO the program needs to be able to tell these functions about
> it, probably through a global variable 'bool ignore_epipe' or similar.

I think this is not necessary.  Most of the time, programs have no need
to distinguish *which* pipe was in error, so they are okay with SIGPIPE
or SIGCHLD.  The global would be needed for programs that deal with
multiple pipes, cannot rely on SIGCHLD (including the case when they
want to be 100% correct and don't want to muddle with
async-signal-safety), *and* need to error out if the reader terminates
first.

Paolo