Re: I/O to shell function in zsh coproc

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 6,  7:00pm, Peter Stephenson wrote:
} Subject: Re: I/O to shell function in zsh coproc
}
} On Sat, 05 Feb 2011 10:08:16 -0800
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > 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.
} 
} It's not as simple as setting FD_CLOEXEC for coproc descriptors, then?

No, because the subshell never performs an exec().  This all happens only
when a shell construct is involved -- if, case, loops, functions, etc.

The right thing almost happens if I modify entersubsh() to close coprocin
and coprocout when ESUB_ASYNC is set:

schaefer<501> coproc while read line; do print -r -- "$line:u"; done
[1] 27394
schaefer<502> print -p foo
schaefer<503> read -ep
FOO
schaefer<504> coproc exit
[2] 27395
[1]  - done       while read line; do; print -r -- "$line:u"; done
[2]  + done       exit

So far, so good, but:

schaefer<505> coproc while read line; do print -r -- "$line:u"; done
[1] 27396
schaefer<506> ( print -p foo )
schaefer<507> read -ep
FOO
schaefer<508> ( print -p foo ) &
print: -p: no coprocess
[2] 27398
[2]  + exit 1     ( print -p foo; )

Oops, that last should not fail; entersubsh() [or execpline2() if we
want to handle it one step higher up the call stack] needs to know
exactly when the job that it's forking *is* the coprocess job, not
just that it's an asynchronous shell job.

Currently that appears to mean adding both another Z_* flag alongside
Z_ASYNC et al., and a corresponding ESUB_* flag -- I tried but failed
to figure out a way to use only the latter.  Maybe there's some other
clue that I'm missing, here.