
KornShell – Moving forward - siteshwar
http://situ.im/posts/korn-shell-moving-forward
======
mattbillenstein
I think ksh was the first shell I was exposed to vi command-line editing in on
a Sun workstation a long time ago -- I haven't thought about it in years as it
seems bash is so prevalent, but good to so some folks still keeping it alive.

~~~
ams6110
You'll still find it as the default shell on at least some BSDs, and I think
AIX.

~~~
ereyes01
AIX defaults to ksh88. My first job out of college a long time ago was to
maintain and enhance AIX's various installers, which involves some 100KLOC
(!!) of ksh scripts. I was one of the first people on the team to move newer
projects to Perl- this was early 00's and somewhat fashionable back then, and
the only other scripting language supported on AIX at the time. In retrospect,
it's possible everything might have been better off left as ksh :-)

~~~
chasil
Commercial UNIXen that bundled CDE had _two_ ksh versions - ksh88 installed as
the POSIX shell, and ksh93 installed as the CDE graphical shell as
/usr/dt/bin/dtksh.

The dtksh binary bundled Motif X/Windows support, and scripts could easily and
quickly build complex GUI applications. This actually remains the fastest and
least resource intensive way to build a quick GUI.

[https://sourceforge.net/projects/cdesktopenv/](https://sourceforge.net/projects/cdesktopenv/)

The dtksh was written at Novell by Pendergrast, who wrote a textbook on it.

Modern ksh93 should make this a supported compile option.

------
webreac
At work, in the scope of a migration from RHEL 6 to rhEL 7, I have spend a lot
of time migrating scripts from ksh (pdksh) to bash in order to remove this
dependency. I have not seen any advantage of ksh over bash. There are many
differences (ksh is less strict), but IMO there is no point in keeping 2
mostly similar but incompatible shells when less and less people are using
shell. I think ksh should die. Maybe I am missing something ?

~~~
derekp7
The biggest benefit of real ksh, to me, is that variables don't disappear in
weird cases, such as:

    
    
        cat file |\
        while read stuff
           do other stuff; set variable
        done
    

In ksh93, variables set within the while loop stay around outside of it.
Whereas bash will run the while loop in a forked sub process.

~~~
sli
That just sounds like (practically speaking, if not totally accurately) local
scoping.

------
nn3
There's basically nothing to see here. One or two minor bug fixes, a few
cleanups, and a new build system replacing one that already worked fine.

In my experience replacing the build system and doing nothing else is usually
a good indicator for a project that will be soon abandoned. If that's the
first priority it means there's no real drive to implement anything new.

~~~
siteshwar
> a new build system replacing one that already worked fine.

Have you actually tried the legacy build system before making that comment ?
If not, I would suggest you to try that. It's by far the worst build system I
ever dealt with. Just to give you an example, if there's a compilation failure
in the middle of build process, build system will not stop, it will continue
to compile everything that it should not compile and then exit with status 0.
There was an absolute need to replace it with something newer.

Replacing the build system is just the first step towards improving the code
base and it's not the end of it.

~~~
nn3
yes i built ast quite a few times. nmake always worked fine.

~~~
siteshwar
I was doing lot of refactoring around ksh93 code and legacy build system was
not really helpful in detecting problems. It was best to change it.

