Re: zsh vs. ksh coproc redirection semantics

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On May 7,  2:17am, Zoltan Hidvegi wrote:
} Subject: Re: zsh vs. ksh coproc redirection semantics
}
} Let me quote the ksh manual:
} 
}        <&digit-      The file descriptor given by digit is  moved
}                      to  standard input.  Similarly for the stan­
}                      dard output using >&digit-.
} 
}        <&-           The standard input is closed.  Similarly for
}                      the standard output using >&-.

I'm curious.  In zsh and bash (which also lacks the <&digit- form), <&-
closes the standard input of whatever command it suffixes, not of the
shell itself.  Which must mean that (semantically, if not in actual
implementation) stdin is first dup'd (as it always is when running a
new command) and then the dup is closed.

Is that what happens in ksh?

Is that what happens to fd `digit' in the <&digit- form in ksh?  I.e.,
does `digit' actually go away for good only upon `exec <&digit-` ?

If not, does
	cat <&0-
close the shell's standard input (leaving it connected to cat)?

If so, all I can say is, ick.  Yet, if you take `p' to be shorthand
for "the digit that is connected to the coproc, followed by `-'"
then that's the behavior of

}        <&p           The  input  from  the co-process is moved to
}                      standard input.
} 
}        >&p           The output to the  co-process  is  moved  to
}                      standard output.

which seems like yet another potential inconsistency that zsh might be
better off not having.

Incidentally, that documentation matches what zsh does much closer than
it matches what Bernd Eggink described ksh as doing.  According to that
excerpt, `exec 3<&p 3<&-` should have no effect on the input _of_ the
coprocess.

} Bart wrote:
} > 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'm not sure I understand what you mean here.  Looks like you are
} confused about terms.

No, I know all that stuff about pipes.  I was trying to express concepts
that it seemed ksh wanted those redirections to embody, rather than the
way it has to be implemented underneath.  But now that I see the doc, I
think Bernd's description was of a ksh that got its own implementation
wrong, which is why my attempt to explain it doesn't work either.

} About the job table: ksh places the coprocess to the job table similarily
} to zsh.  You can bring the coprocess to the foregroung with fg, which
} does not makes much sense, but works.

Probably fg followed by ctrl-C is a common kill-the-coproc technique.

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