Re: zsh vs. ksh coproc redirection semantics

[Bernd Eggink <eggink@xxxxxxxxxxxxxx>]

Bart Schaefer wrote:
> 
> On May 5,  1:39pm, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } On Mon, 4 May 1998, Bart Schaefer wrote:
> }
> } >     cat <&p
> } >
> } > what happens?  The input _of cat_ is connected to the _output_ of the
> } > coproc, right?
> }
> } Hm, I admit that I never tried this in zsh... In fact, it works
> } like this in zsh, but exactly the OTHER way round in ksh.
> 
> So you're saying that in ksh, cat <&p means that the coproc input is
> closed and cat takes its input from wherever the coproc was getting its
> input?  That makes no sense at all.  (Which tells me that `exec 3<&p`
> must be doing something special in ksh, if indeed it acts as you say.)
> 
> } In ksh 3<&p means "duplicate the coproc input to unit 3".
> 
> I think maybe we're having a cognitive dissonance here. 
[ ... ]

Possibly... I'll try to be more specific:

In ksh, 3<&p means "duplicate the input _the coproc is reading from_ to
3". I consider that consistent with the fact that (in ksh as well as in
zsh) 3<&0 means "duplicate the input that is currently read from to 3".
Of course it doesn't make much sense to copy an input, except for the
purpose of closing it. And you must duplicate the coproc input for
closing, unless a special syntax is provided for that purpose; you can't
say "exec p<&-", because that, of course, would mean something
completely different.

> } IMHO this is more consistent and intuitive than what zsh does.
> 
> Really?  I think having inputs connected to outputs is more intuitive
> than having inputs duplicated.

In ksh, the connection is done by 'read -p' and 'print -p'. You can't
say "print foo >&p" or "read bar <&p", whereas in zsh you can say either
"print -p foo" or "print foo >&p". What I meant by "inconsistency" is
that in zsh >& and <& mean different things, depending on whether a 'p'
or a digit follows. This may be considered a matter of convention, but
in effect it prevents you from duplicating the coproc input, and such
from closing it (which, if I remember right, was your original problem).

As I just noticed, ksh has it's inconsistencies, too. While you can't
say "print foo >&p", you can say "exec 4>&p; print foo >&4", and it
works. Hm...

Reconsidering all that, I think the idea of connecting the coproc's
output and input to arbitrary file descriptors would in fact be the most
elegant solution.

Regards,
	Bernd

--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@xxxxxxxxxxxxxxxxxx
http://www.rrz.uni-hamburg.de/eggink/BEggink.html