Re: Enhancement request for tee - please add the option to not quit on SIGPIPE when someother files are still opened

[Jirka Hladky]

I am going to suggest this without trying it, always dangerous, but I
have no time for a deep investment.  Sorry.  What about closing
stdout?  Then it would be closed right from the start.
  1>&-
Except that the no-exit behavior is only on pipes.  So I guess it
would need to have a pipe created just to have it closed.
  | cat 1>&-

You post came when I was writing mine. I don't like closing stdout completely. Using >/dev/full is really what I want (closing only stdout for tee process) even if I think it would be much better to have the option --no-stdout so that tee does not write to stdout at all if user does not want to. 

The general problem I have with >(process substitutions) are that they
are completely asynchronous.  There is no way to tell if they are
done.

Yes, I agree with you on this one. However, I don't see the other way how to send the output of one process to multiple sub-processes in shell. In the past I have solved the problem by adding directly to RNG source code popen calls to send it's output to multiple tests. tee and >(process substitutions) is better solution.

To come to a conclusion: Bob, what is your thought to implement  --no-stdout option? 

Jirka

On Fri, Nov 20, 2015 at 1:58 AM, Bob Proulx <address@hidden> wrote:

Pádraig Brady wrote:
> Jirka Hladky wrote:
> > => it's almost there expect that it runs forever because of >/dev/null

I am going to suggest this without trying it, always dangerous, but I
have no time for a deep investment.  Sorry.  What about closing
stdout?  Then it would be closed right from the start.

  1>&-

Except that the no-exit behavior is only on pipes.  So I guess it
would need to have a pipe created just to have it closed.

  | cat 1>&-

> Right, the particular issue here is that the >(process substitutions)
> are writing to stdout, and this is intermingled through the pipe
> to what tee is writing to stdout.

The general problem I have with >(process substitutions) are that they
are completely asynchronous.  There is no way to tell if they are
done.

  rwp@fencepost:~$ echo foo | tee >(sleep 5 && cat)
  foo
  rwp@fencepost:~$ sleep 3 && echo sleep 3 done
  sleep 3 done
  rwp@fencepost:~$ foo

I complained about that on the bash list a couple of years ago.  There
appears to be no way to synchronize those proceses back together
again.  No way to join the forked flow.  For my sensibilities that
makes the utility much reduced to only those things that you don't
care when the task finishes.  In the above that later output may
appear at any time.  It is likely to appear in sequence but there is
no guarantee of it.  What if the task is waiting on the network such
as doing a dns lookup?  What if the machine is heavily loaded and the
process is delayed?  Then the task may be delayed indefinitely and may
finish at any arbitrary time.

> So in summary, maybe there is the need for --no-stdout,
> though I don't see it yet myself TBH.

I haven't come across a use for it in my own programs.  There doesn't
seem to be significant requests for it.  But I am not opposed to it.
At this time I don't see any fundamental problems in the tee side of
things.  The only problem is that people using the shell >(...) side
of things have the problem of no way to wait for the children to
finish and no way to join the forked flow.  That in the shell is a
serious problem as far as I am concerned.  I wouldn't use it until
the shell side gets more fully featured out.

Bob