Re: coproc tutorial (Re: questions)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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.