Re: tee logs no output if stdout is closed

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> Jim Meyering wrote:
>> > ... 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.
>
> I agree that having SIGPIPE blocked or ignoring during an execve() or
> posix_spawn() call is a bad idea. The best strategy for a program that
> wants to write to a subprocess is therefore to
>   0. ensure the SIGPIPE handler is set to SIG_DFL.
>   1. spawn the subprocess,
>   2. switch the SIGPIPE handler to SIG_IGN,
>   3. start writing to the subprocess.
>
>> > 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?
>
> 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.

> That would satisfy the "don't know which of the two terminates first" scenario
> (the 'msgfilter' case), and your scenario of "writer must terminate first"
> as well.