Re: coproc tutorial (Re: questions)

Re: coproc tutorial (Re: questions)

[Jay Sekora]

It seems a little bit non-orthoganal that you can only have one
coprocess.  (And I think that probably defeats some of the potential
value of coprocesses, which otherwise would let multiple background
pipelines communicate with each other in arbitrarily complex ways.  Has
anybody thought about the possibility of adding support for multiple
coprocesses to some misty future version of zsh?  Or am I missing the
point of supporting a coprocess?  (Entirely plausible, since I've never
used them.)

-j.

Re: coproc tutorial (Re: questions)

[Bart Schaefer]

On Oct 4, 12:10pm, Jay Sekora wrote:
> Subject: Re: coproc tutorial (Re: questions)
> It seems a little bit non-orthoganal that you can only have one
> coprocess.

It's not the case that there can be only one coprocess.  The restriction
is that there can be only one pair of file descriptors referred to by the
special "p" name, and closing them frequently has the effect of stopping
the coprocess; but if you've copied those descriptors elsewhere you can
still use the copies to communicate with the process.

E.g.

    coproc tr a-z A-Z
    exec 5>&p			;: descriptor 5 is now the input of tr
    exec 6<&p			;: descriptor 6 is now the output of tr
    coproc sed s/DOG/CAT/ 5>&-
    exec 7>&p			;: descriptor 7 is now the input of sed
    exec 8<&p			;: descriptor 8 is now the output of sed
    coproc exit			;: close p
    cat <&6 >&7 5>&- 7>&- &	 : tr is now connected to sed
    exec 6<&- 7>&-		;: close shell copies of descriptors
    echo dog >&5		;: send tr some input
    exec 5>&-			;: close 5 so tr will exit
    cat <&8			;: should print CAT

There are some oddities here ... first, note how I had to explicitly close
descriptor 5 in the second coproc, and 5 and 7 in the backgrounded "cat".
That's because they don't have the close-on-exec flag set; if I don't close
them, "tr" and "sed" never see end-of-file.  I'm not sure whether that is
correct behavior or not.

Second, this doesn't actually work in 3.0.6, because zsh "leaks" copies of
descriptors 5 and 7 as descriptors 13 and 14 ("strace" is your friend), so
even after all my careful descriptor-closing I still can't get "tr" to see
EOF.  It works in 3.1.6, so I may have a look at fixing it in 3.0.

Elusive coproc bug (Re: coproc tutorial (Re: questions))

[Bart Schaefer]

On Oct 4 I wrote:
} Subject: Re: coproc tutorial (Re: questions)
}
}     coproc tr a-z A-Z
}     exec 5>&p			;: descriptor 5 is now the input of tr
}     exec 6<&p			;: descriptor 6 is now the output of tr
}     coproc sed s/DOG/CAT/ 5>&-
}     exec 7>&p			;: descriptor 7 is now the input of sed
}     exec 8<&p			;: descriptor 8 is now the output of sed
}     coproc exit		;: close p
}     cat <&6 >&7 5>&- 7>&- &	 : tr is now connected to sed
}     exec 6<&- 7>&-		;: close shell copies of descriptors
}     echo dog >&5		;: send tr some input
}     exec 5>&-			;: close 5 so tr will exit
}     cat <&8			;: should print CAT
} 
} [...] this doesn't actually work in 3.0.6, because zsh "leaks" copies of
} descriptors 5 and 7 as descriptors 13 and 14 ("strace" is your friend)

I've now completely failed to duplicate this bug both on the machine where
I first noticed it and on my machine at home, so it must depend on some
other thing that I did earlier within that same shell.  That worries me
a bit, so if any of you happen to feel like experimenting with this (or
have any idea what may be going on), I'd appreciate hearing about it.

Meanwhile, the above appears to work as expected in a freshly-started zsh
of either version series.

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