Re: zsh vs. ksh coproc redirection semantics

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

On May 6, 12:47pm, Bernd Eggink wrote:
} Subject: Re: zsh vs. ksh coproc redirection semantics
}
} 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".
} [...]
} 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.

No, that's not true.  3>&1 means to copy the shell's standard output to
descriptor 3.  3>&p means copy the shell's coproc output to descriptor
3.  3<&0 means copy the shell's standard input to 3.  3<&p means copy the
shell's coproc input to 3 (not move the coproc's input to 3).

Ksh, on the other hand, appears to treat <&p as "the coproc end of the
two-way pipe" and >&p as "the ksh end of the two-way pipe".  This isn't
the same as other descriptors, but then other descriptors aren't pipes.

I think zsh's treatment ends up working a bit more consistently, because
you can always think of descriptor behavior in terms of where the current
shell will get or put data.

} 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).

I still think (based on what you've said in previous messages) that this
particular detail is not very consistent in ksh.  In zsh, if I do
	exec 4<&0
	exec 4<&-
then that closes only descriptor 4, not descriptor 0.  Why should
	exec 3<&p
	exec 3<&-
close both 3 and p?  In ksh, if you do
	exec 4>&p
can you later do
	exec 5>&p
and end up having both 4 and 5 connected to the coproc pipe at the same
time?  My guess is that you can't -- that once you've done 4>&p, then p
is gone and you can't do 5>&p.

Now, the question is, whether this particular inconsistency with p and
other fds is useful enough to emulate it.

(Is anybody on zsh-workers reading this?  Zefram, Zoltan, Peter?)

} 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.

I still think that's completely independent.  It doesn't matter what
descriptors you can connect it to without some kind of special handling
to close the original descriptor at the same time that you close the one
you connected it to.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com