bug#6900: mktemp: want option to make a fifo

[Paul Eggert]

On 08/24/2010 11:03 AM, John Reiser wrote:
> This can work for B2, B3, ..., B8 but cannot handle more because shell
> is allowed to balk at redirecting fd greater than 9.

That is not a problem in practice.  The limit of 10 descriptors does
not mean that one can't create more than 10 pipes in one's shell
script.  All it means is that one can't have more than 10 useful pipes
active at any given position in one's shell script.  I've never had
the need to have more than 10 pipes connected to a component, and I
imagine that any component that needs more than 10 pipes connected to
it should be simplified anyway.

> I also prefer to think about the situation as "B1 is doing fan-out
> multiplexing" rather than "C is doing fan-in multiplexing", because
> the "C" end is more "constant" and the "B" end is more "variable".

OK, but that sort of high-level thinking is one level of abstraction
above named fifos and pipes, and in this case one can implement it in
terms of either named fifos or pipes.  Admittedly one needs to get
used to the implementation strategy.

> I dislike the part "(b1 | maybe_b2)" because in practice it tends to
> be fragile.  When things go wrong it is hard to diagnose and
> recover.

True, but it's hard to diagnose named fifos as well.  I can use
"tee" to debug either sort of shell script, and don't find it any
harder to debug the piped version.  I'm not sure what is meant by
"recover".

> Also, I do not see how to extend it for the case of more than one
> conditional process whose startup should be delayed (B3, B4, ...),
> such as the 'sed' in "read line&&  sed ...".

I don't quite follow the question, but if we're talking about
multiple file descriptors for b1, each treated like the pipe to b2,
surely this can be done with something like this:

  a | ((b1 3>&1 >&5 | maybe_b3) 4>&1 >&5 | maybe_b4) 5>&1 | c

Here b1's file descriptor 3 goes to b3, and its file descriptor 4 goes
to b4.