> I actually sorta like pdksh.  The licensing terms are less
> restrictive, and I don't see any reason to favor one
> implementation over another just because it got there first.

There's an enormous functionality gap.  ksh is a full
standalone/embeddable scripting language that can be dynamically
extended with new commands and disciplines or embedded as scripting
language by a program, operate on arbitrary binary I/O, do date/time
computations, documentation generation, i18n and l10n, built on reusable
libraries that support all of those functions, stackable I/O disciplines
and filters, and I'll stop because you get the picture.  pdksh is a
shell program that accepts a language kinda like ksh's from ~11-12 years
ago.

I don't have anything against pdksh as pdksh, but I do think it's
inconvenient when an OS ships with a program named /bin/ksh that won't
run ksh scripts.

Part of the reason more people aren't familiar with what ksh can
actually do is our package in pkgsrc does only a partial installation;
it installs only the ksh binary and ksh.1 manpage, not libshell.so and
libast.so or any of the headers, library man pages, or other docs for
extending or embedding it. That would be sorta like a Tcl package that
didn't install libtcl.so. I think the AT&T guys are working toward a
next formal release RSN, and when they do that I'm thinking to put in
the effort to update our pkgsrc package so it's not only up-to-date but
also complete.  That would be a step toward later conversations about
whether to include it in the distribution, and it would help clear up
the misconception that pdksh-is-pretty-much-comparable-to-ksh, more
easily than talking about it.

-Chap