Re: tee logs no output if stdout is closed

[Bruno Haible]

Jim Meyering wrote:
> If there is an EPIPE error, IMHO, close_stream must diagnose it.

Well, then here is an amended patch (just for coreutils: 0001 and 0002,
with a single ChangeLog entry) for the 'tee' program.

The idea behind the patch is as follows:

SIGPIPE is an optimization through which the readers of a pipe can communicate
to the writers of the pipe "save your effort, no one is interested in your
output any more".

Suppose "tee /some/pipe-or-socket" is invoked. The 'tee' process has one
input and two outputs (stdout and /some/pipe-or-socket). If any of the output
destinations are shut down, the 'tee' process will get a SIGPIPE signal during
the next write() call. According to POSIX, 'tee' must terminate in this
situation.

Viewing SIGPIPE as an optimization, a different behaviour is useful:
When the first of the output destinations is shut down, 'tee' continues
to forward the input to the second destination. When the second destination
is shut down as well, _then_ there's no point for more input, and 'tee'
can terminate itself.

The new option '-p' implements this behaviour.

The reason for patch 0002 is to handle the case that some output destination
shuts down immediately after the input is terminated. In this case you
don't want a diagnostic; it's better to let the 'tee' process die from a
SIGPIPE in this case. This is the purpose of the line
   signal (SIGPIPE, SIG_DFL);

Bruno

0001--New-tee-option-p.patch
Description: Text Data

0002-Restore-the-default-SIGPIPE-handler-before-exiting.patch
Description: Text Data