bug#6900: pitfalls of recoding named fifo as pipe

[Paul Eggert]

On 08/25/2010 07:14 AM, John Reiser wrote:
> That is not equivalent!  stdout from listener1 gets piped into
> cmd2, instead of going to the common stdout of all processes
> other than cmd1.

Yes, you're right.  I had assumed that the listeners did not generate
standard output.  If they do, it should have been this:

  ((cmd1 2>&1 >&3 | listener1 >&4) 3>&1 |
   (cmd2 2>&1 >&4 | listener2    )
  ) 4>&1

> Also, file descriptor 3 is left open in all processes, which
> hogs system resources and is less safe.

Those resource and safety issues are typically negligible.
If one wanted to be extremely cautious, one could write this:

  ((cmd1 2>&1 >&3 3>&- 4>&- | listener1 >&4 3>&- 4>&-) 3>&1 |
   (cmd2 2>&1 >&4      4>&- | listener2          4>&-)
  ) 4>&1

(This is a shorter and POSIX-conforming way of writing the variant
that you sent, plus it fixes a couple of bugs in the way that variant
redirected file descriptor 2.)  But almost nobody would or should
bother with this level of complication.

> Using the named fifos is much more readable and understandable.

Yes, as I said, once things get sufficiently complicated, it's quite
possible for named fifos to be easier to use.  It's still not clear to
me that this is the case here, as even the overly-complicated piped
version is a tad simpler than the named-fifo version.  But the point
remains that, once a script is complicated enough to need a lot of
named fifos, it should be using mktemp -d anyway.