Greg A. Woods wrote:
> > to NetBSD various ksh scripts from a lengthy career of writing ksh scripts
> > and finding they don't run because the thing in NetBSD called /bin/ksh
> > isn't ksh.
> 
> Indeed, BUT, see this first:
> 	http://web.cs.mun.ca/~michael/pdksh/NOTES

Thank you for reminding me of this file.  It contains a terse, 1800 word, and
likely incomplete, enumeration of the ways pdksh diverges from ksh.
 
> Remember too that if you're writing scripts you expect to be portable
> then they should restrict themselves to features available universally
> in all POSIX-compatible shells.

Not a bit of it, in this case. I never set out to write "portable POSIX shell
scripts."  I wrote Korn Shell, i.e. ksh, scripts, which run to perfection on
ksh, which is available for many platforms and many OSes from its author,
David Korn, and his employer, AT&T.

Now.  Imagine some bloke writes a program he is pleased to call "pdTcl",
which interprets a language he has roughly based upon the language Tcl,
provided one overlooks a terse 1800 word enumeration of divergences.

Now imagine we ship a base system that includes "pdTcl" under the name tcl.
And imagine that when users bring over their genuine Tcl scripts, and find
that "pdTcl" can't run them, we point them to the 1800 word list of ways that
"pdTcl" isn't Tcl, and suggest they somehow shouldn't have expected the
program named tcl to be tcl, or to be able to run tcl scripts.

> It's also a heck of a lot smaller and faster than modern ATT Ksh.

Now imagine the conversation continues, with apparently no sense of comedy,
into a discussion of the relative size and speed of "pdTcl" and Tcl (which
we have now begun calling "Scriptics Tcl" for some reason), as if to use that
as the basis of the decision whether Tcl ought to be Tcl, or something called
Tcl with an 1800 word list of incompatibilities.

This is why I am coming around to Sascha Retzki's position.  I would
personally love to have ksh in the base, but I can live with it being a
package, and I respect the parsimony arguments for keeping it there.
But then, having something that ain't ksh included in the base and called
ksh is just wacked.  There could just as easily be a pdksh package (that
installs a binary named pdksh) for use by people who have invested heavily
in pdksh scripts they can't get to run in ksh.

> > All that said, I did offer not long ago to update the ksh package in pkgsrc
> > so that it provides a complete, current ksh implementation.  I haven't had a

> You mean like pkgsrc/shells/ast-ksh already does?!?!?!?

I meant more like pkgsrc/shells/ast-ksh currently doesn't.  That's why I'm
working on updating it.  :)

-Chap