Zbigniew Baniewski wrote:
> > 	For anyone that wants a quick answer, a few of the features I picked out
> > that pdksh doesn't seem to have:
> 
> I'm afraid, all that will be considered as "bloat"

Hi,

Could you clarify whether you yourself consider the features of ksh to be
bloat, or you are afraid that others will?

To me the most frustrating part of the current situation is porting over
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.  Then one gets into the mess of not daring to write a ksh script because
it's too embarrassing to explain to people why it won't run on the thing their
system calls /bin/ksh, and therefore being backed into choosing an entirely
different language for something that could be easily done as a ksh script,
but only verbosely and painfully done as a "pdksh" script.

Richard Rauch had kind of a funny way of putting it:

> I've had some problems when trying to settle into an AT&T ksh.  I.e.,
> it's not a superset of our /bin/ksh.

We're now calling ksh "AT&T ksh" and comparing it to an incomplete approximate
public domain knockoff we happen to call /bin/ksh?  ksh stands for ... Korn
shell.  It was written by ... David Korn.  It comes from ... AT&T.  And, true,
to state it in the more natural direction, pdksh does not qualify as a subset
of 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
lot of time to work on it yet, but I suspect it makes sense to start with
an updated package to talk about before raising the issue of including it
in base.

-Chap