Joerg Klemenz writes:

>Also the scrolling (non-wrapping) line editor sucks big time.

It's the same as in the original ksh.  Whether it sucks or not
is imho open to discussion.  It still works on ordinary terminals
(your DEC vtXXX box) where shells that edit more than one line
like tcsh or bash more often than not just fail once it wraps around.
At least the original ksh also works on really dumb terminals which
just support non-destructive backspacing (like all ordinary terminals
at least ought to provide.)
If at all, please don't incorporate something like libedit into
pdksh, which would depend on full termcap/info/curses support.

>Also the lack of a .kshrc file or whatever forces you to put ksh
>specific stuff in .profile or $ENV and ifdef it out which doesnt
>always work.

You just check for $RANDOM being empty or not.  That's the
canonical way of finding ksh (you can further distinguish from,
for example bash, by checking for BASH_VERSION).
Newer ksh93 have the .sh.version variable but pdksh aswell as
ksh88 don't support that syntax (and don't have the variable).
Pdksh sets KSH_VERSION but neither ksh88 nor ksh93 do.

>Are there any chances that our ksh will be enhanced one day?

I'd prefer not to have any further enhancements that are not in
the original ksh(93).  I'd like to have things fixed that differ
from the original ksh (like the echo hi|read a; echo $a issue)
and missing ksh88 features added.  IMHO there isn't the need to
push it up to the ksh93 feature set (ksh93 is freely available
by now), not that it would be possible without a _lot_ of work
anyways that would probably amount to a complete reimplementation
of ksh93.

I like it that pdksh has a useful feature set and still is
amongst the smallest shells available with such a feature set
(making it ideal for low-mem systems.)  It's also very portable.

-- 
Matthias Buelow,
de.mukappabeta@mkb