Re: [Help-bash] Creating an anonymous pipe for later use

[Russell Lewis]

They work according to spec - I'm not claiming that they are buggy.  But 
they have more pitfalls than anonymous pipes.

Key ones I stumbled on:

1) Need to clean up filesystem artifacts; hard to do
   this promptly without races (removing the file
   before it is used)

2) Can't open just one side of a pipe - open() will
   block.  So kicking off two commands from the same
   script, and connecting them with a named pipe, is
   possible (but very hard to do without deadlock)

3) A child process cannot open /dev/fd/0 (to get a dup
   of the parent script's stdin) if stdin is a named
   pipe; open() will block (on Linux).  On other *NIXes,
   I have read that the open() will just dup() the file
   descriptor (which is what I wanted) - Linux works
   differently.

For the record, the way to kick off two commands from the same parent 
script, connected through a named pipe, without either races or 
deadlock, is as follows:
    tmp=$(mktemp -u)
    mkfifo $tmp
    cmd1 >$tmp &        # opens the pipe in the child process.
    { cmd2 & } <$tmp    # opens the pipe in the parent process.
                        # open() blocks until both sides have
                        # started it.
    rm $tmp

Ick.

Russ

On 10/09/14 13:43, Bob Proulx wrote:
> Russell Lewis wrote:
> > Linux's support for named pipes is less robust than its support for
> > anonymous pipes.
> What isn't robust about them?  I have used them extensively and I
> haven't found anything not robust about them.  Therefore I suspect
> simply a misunderstanding of some sort.
>
> > I've done a lot of experimentation with them, and have come to the
> > conclusion that I should use anonymous pipes if at all possible.  (I
> > can give details in a separate email if anyone is interested.)
> Bob