Re: tee logs no output if stdout is closed

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> > EPIPE is part of the normal shutdown
>> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE.
>>
>> First, you're assuming that the pipe writer chooses to
>> block or ignore SIGPIPE
>
> Yes, EPIPE only occurs if SIGPIPE is blocked or ignored.
>
>> which is not generally recommended.

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

> Huh? There is no authority that recommends leaving SIGPIPE's handler set to
> SIG_DFL. In fact,
>   - SIG_DFL is appropriate for programs whose only purpose/effect is to write
>     something to standard output and standard error. (The majority of the
>     Unix programs.)
>   - SIG_IGN is appropriate for programs whose main purpose is to do side 
> effects.
>   - SIG_IGN is appropriate also when writing into the stdin of child processes
>     which may or may not read all the input before exiting. 'msgfilter' is
>     such a program.
>
>> 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.  With your
>> modification, a pipe writer using close_stream would be unable to detect
>> a write failure due to EPIPE.
>
> The pipe writer will be the parent process of the pipe reader in this case,
> right? (If it's the other way around, the pipe writer should better terminate

What if the writer and reader processes have no such relationship?

> when the pipe reader is gone, hence it should have SIGPIPE set to SIG_DFL.)
> Then the detection whether the pipe reader has terminated unexpectedly should
> better be done through the exit code, IMO, rather than by continually writing.
>
> In this scenario, the pipe writer is expected to terminate before the pipe
> reader.
>
> The majority use-case of pipes is when you don't know ahead of time which
> of the two processes, pipe reader of pipe writer, will terminate first.
> In this case, EPIPE may occur as part of normal operation, depending on the
> timing of the two processes. close_stdout is not currently usable in this
> situation.
>
> 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.

Using a global variable would not be appropriate for library code like
this.  What if two applications using the same library want to use
different policies?

While I don't like the alternatives much,
they're better in the long run.