I/O to shell function in zsh coproc

I/O to shell function in zsh coproc

[Rory Mulvaney]

I think this is a bug in zsh (4.3.10), I can't figure out what is wrong:

function wcFunc() {
   wc
}

# coproc wc : works with plain wc
coproc wcFunc
wcf=$!
# copy the write and read fd's for the coproc
exec 5>&p 6<&p
# start another null coproc to get a new target for the p fd
coproc exit
echo hi there >&5
# close the fd, so hopefully the coproc would exit, but it doesn't
exec 5>&-
# sleep $LONGTIME
# kill $wcf
var=$( cat <&6 )
echo $var

As noted, it works when I use plain wc, rather than wcFunc.  Of course, 
it's a lot more useful if it would work with shell functions.  It also 
works if you kill the coproc, but in the general case you'd need to first 
wait for the estimated time it takes for the coproc to complete, and you 
might not be at all sure how long it will take.

Thanks and regards,
Rory

Re: I/O to shell function in zsh coproc

[Bart Schaefer]

On Feb 5, 11:22am, Rory Mulvaney wrote:
>
> I think this is a bug in zsh (4.3.10), I can't figure out what is wrong:
> 
> function wcFunc() {
>    wc
> }
> 
> # coproc wc : works with plain wc
> coproc wcFunc

You're right, there is a bug there.  I'm not immediately sure where to
fix it, but there's a workaround.

The bug is that when you do 'coproc shellfunction', zsh has to fork a
subshell to run the shellfunction in another process.  The trouble is
that the subshell therefore gets copies of the coprocess descriptors
that are open in the parent shell.  If the subshell later forks off
a job (wc in this example) and waits for it, it will hold that job's
standard input open forever.

Related:  It'd be nice if SHLVL was incremented when entering this
special-purpose intermediate subshell, but it isn't.

The workaround until this is repaired is to force the coproc descriptors
closed in the function the same way you're later going to force them to
be closed in the parent:

    wcFunc() {
      coproc exit
      wc
    }