> > 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 <[email protected]> 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 > >
