And shouldn't there be an entry for "coproc" in the documentation under one
or the other of "Shell Builtin Commands" or "Precommand Modifiers"? Having
it buried only in the middle of a paragraph in "Simple Commands" is not very
helpful.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
That's easily accomplished already, by e.g. 3<&p or 4>&p. The odd bit is
that when ksh does >&p, it -closes- the "p" descriptor after dup'ing it.
When zsh does >&p, it leaves "p" open, so you can do >&p again to the same
coprocess. (This is not true of <&p, which makes me think >&p has a bug.)
This has some interesting side effects, one of which is that there's no
way to explicitly close down the coproc input (except to start another).
} so that one could close either pipe with the ">&-" syntax. This would
} also make it possible to have multiple independent coprocesses.
That's also already possible, as someone on the zsh-users thread pointed
out.
coproc first-coproc
exec 3<&p 4>&p
coproc second-coproc
exec 5<&p 6>&p
coproc etcetera
} To do this properly I think we'd need an extended redirection syntax,
} to allow redirecting file descriptors of more than one digit
That's completely orthogonal.
} perhaps we could do something like the rc syntax?
I don't know what that is.
Coprocesses are a bit of a mess. I'd like to make it possible to attach
the coprocess to specified fd numbers, just like file redirections,
so that one could close either pipe with the ">&-" syntax. This would
also make it possible to have multiple independent coprocesses. To do
this properly I think we'd need an extended redirection syntax, to allow
redirecting file descriptors of more than one digit; perhaps we could
do something like the rc syntax?
-zefram