Re: FIFOs

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 14,  6:05pm, Peter Stephenson wrote:
} Subject: FIFOs
}
} % 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).  There's no easy way to
} synch this, since you end up with deadlock --- the child can't open the
} fifo until there's a process reading it.

The obvious solution here is that zsh should fork a subshell to handle the
entire process inside the <(...), including actually removing the file at
the end.  That is, the parent creates the FIFO, then forks a subshell.  The
subshell runs "echo foo" and then removes the FIFO when that exits.

Meanwhile, the parent runs "echo nameofFIFOhere" and treats the subshell as
a backgrounded job.  It never touches the FIFO again.

} 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.

If the user asked for that, then that's what the user gets.  In the
scenario I just described, it's the subshell that sits around forever,
not the parent; so what?  It's not like the terminal is hung.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com