[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: Jim Meyering
Subject: Re: tee logs no output if stdout is closed
Date: Sat, 04 Oct 2008 11:49:09 +0200

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.

reply via email to

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