RE: FIFOs again

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

As you intend to release 3.1.7, can we try to sort this out before?

First, current docs are a bit incorrect. Shell passes FIFO or /dev/fd/n,
which is in reality pipe (if I understand implementation correctly). So,
both are not seekable, while docs imply, that only FIFO case is not.

And more about FIFO case.
>
> % echo <(echo foo)
>
> Here the parent shell can, with the wind in the right
> direction, get back
> and delete the file named by the <(...) before the child has
> had a chance
> to open it (let alone call the code to fill it).
....
>
> One good reason not to worry about this is that if the
> process actually
> opens the fifo, that's guaranteed not to happen, i.e.
>
> % cat <(echo foo)
>
> always works.
>

Yes, I agree. This should not be an issue.

>
> The second thing is a killer, at least without a rethink.  In the case
> first shown, where the fifo is never opened, but this time does still
> exist, the zsh just hangs on for ever waiting for it and sits around
> uselessly in the process table.


Yes, I got the same. Real nasty. One possibility is "dummy open" in
parent. The child hangs because it tries to open FIFO without
counterpart. Parent can simply open it and then close when child exits
or we're done with current commmand (it currently have to delete FIFO
anyway).

-andrej