bug-coreutils
[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: Bruno Haible
Subject: Re: tee logs no output if stdout is closed
Date: Fri, 3 Oct 2008 15:17:14 +0200
User-agent: KMail/1.5.4

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.

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.

This would also be better than switching back the signal handler to SIG_DFL
right before the call to exit (0) in main(), because close_stdout is registered
as an 'atexit' handler and there are also other calls to exit() in a program,
from xalloc_die() for example.

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

What are the alternatives that you propose?

Bruno





reply via email to

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