KornShell – 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.

[nerdponx]

I've never used it, but I'm deeply grateful for it because, from what I can tell, without Ksh we wouldn't have Zsh, which I use every day and really enjoy.

[alxlaz]

OpenBSD still uses a ksh fork as a default shell. mksh is also widely-available and pretty great -- I use it as my shell on Linux boxes, too.

[fapjacks]

My first shell was ksh on a DEC Unix many years ago. That was the first scripting I ever did.

[ams6110]

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

[GrumpSlverBear]

ksh was not my first shell, but as much as you, it is where I use vi command-line editing a lot. It's one of the first shells I really got to grip with as a young budding system administrator. I didn't know any vim really before I went on a Sun scripting for sysadmin course. My Ksh scripting book has served me well over the many years.

[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 ?

[chasil]

There are TONS of advantages to ksh93 over bash.

-Floating point math, not just integer

-Coprocess syntax that is correct and compliant

-Genuine Korn retains variables in control structures

-Lots more, detailed in the Korn & Bolsky ksh93 book

The language specification for ksh93 is large and powerful, and bash doesn't approach it.

[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.

[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.

[matttproud]

I hadn't been aware of this project, but I am thankful it exists as a mksh user. ksh rocks; I love how low-bloat and fast it is. Feature bloat — e.g., distribution package management helper scripts that come preinstalled — slowed down bash. Enough was enough.

To the remark about build system, I would like to offer some speculation: I have (or had?) worked with its maintainer Kurtis by way of common employer on a few projects. He is a fantastic engineer and extremely careful and diligent; from that, I would grant significant deference. His team maintained one of the most sprawling pieces of legacy shell script infrastructure I have seen in my career.

Here's to hoping for a blossoming revival of the original essentials.