6 ms·

KornShell – Moving forward

58 points by siteshwar 9y ago

mattbillenstein 9y ago
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 9y ago
  You'll still find it as the default shell on at least some BSDs, and I think AIX.
  - Crontab 9y ago
    On OpenBSD, the default shell is their fork of pdksh. On NetBSD, it is Almquist Shell, and on FreeBSD, it is Tcsh (IIRC).
    - 0xcde4c3db 9y ago
      On FreeBSD it's tcsh for root and ash for non-root, oddly enough.
      - Crontab 9y ago
        Interesting. Thanks.
  - ereyes01 9y ago
    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 :-)
    - sparcpile 9y ago
      The AIX installp format is my favorite package manager. It was fairly easy to debug it until it hit the ODM. The only time when AIX utility debugging got weird was when multibos went off the rails. I started using ksh on AIX and it has been my favorite shell since then. I've written a few thousand SLOC worth of utilities and customization scripts in KornShell.
    - chasil 9y ago
      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.
- nerdponx 9y ago
  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.
  - StavrosK 9y ago
    If you like zsh, you're going to love fish† † The qualifying clause is probably unnecessary here.
    - discreditable 9y ago
      Maybe even if not! I didn't care that much for zsh but I love fish.
    - reificator 9y ago
      I love zsh, but am not a huge fan of fish. Lots of non-standard things that don't play nicely with existing workflows. I prefer bash/zsh/etc because of the ecosystem around them. If I wanted to throw that away and start from a different base I'd probably use Powershell or something like it to be honest.
    - oboopfmlrmnmn 9y ago
      I love zsh, but abandoned ship of fish long ago.
    - CJefferson 9y ago
      I find fish interesting, because I thought it is what I wanted (throwing away the pain of sh syntax), but now I just have to keep switching between sh and fish and I keep forgetting which is which. I have to write too many scripts for other people, and I can at best assume they have bash. I've gone back to bash, might try out zsh.
      - StavrosK 9y ago
        Why not just write scripts in bash (or, hell, Python?) and use fish as your shell?
- fapjacks 9y ago
  My first shell was ksh on a DEC Unix many years ago. That was the first scripting I ever did.
- alxlaz 9y ago
  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.
  - throwaway2048 9y ago
    its not a fork of ksh, its a fork of an open source ksh clone called pdksh that predates AT&T ksh open sourcing, and is frankly kinda crap. OpenBSD has improved it, but compared to real ksh its lacking quite a lot, most painfully sane substrings.
    - alxlaz 9y ago
      Right. In the spur of the moment I wrote "a fork of ksh" as in "a shell (mostly) conforming to ksh' specs", which is technically incorrect -- the worst kind of incorrect.
- GrumpSlverBear 9y ago
  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.
nn3 9y ago
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 9y ago
  > 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 9y ago
    yes i built ast quite a few times. nmake always worked fine.
    - siteshwar 9y ago
      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.
- matttproud 9y ago
  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.
webreac 9y ago
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 9y ago
  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 9y ago
    That just sounds like (practically speaking, if not totally accurately) local scoping.
- chasil 9y ago
  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.

58 points by siteshwar 9y ago

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 9y ago
You'll still find it as the default shell on at least some BSDs, and I think AIX.
- Crontab 9y ago
  On OpenBSD, the default shell is their fork of pdksh. On NetBSD, it is Almquist Shell, and on FreeBSD, it is Tcsh (IIRC).
  - 0xcde4c3db 9y ago
    On FreeBSD it's tcsh for root and ash for non-root, oddly enough.
    - Crontab 9y ago
      Interesting. Thanks.
- ereyes01 9y ago
  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 :-)
  - sparcpile 9y ago
    The AIX installp format is my favorite package manager. It was fairly easy to debug it until it hit the ODM. The only time when AIX utility debugging got weird was when multibos went off the rails. I started using ksh on AIX and it has been my favorite shell since then. I've written a few thousand SLOC worth of utilities and customization scripts in KornShell.
  - chasil 9y ago
    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.
nerdponx 9y ago
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.
- StavrosK 9y ago
  If you like zsh, you're going to love fish† † The qualifying clause is probably unnecessary here.
  - discreditable 9y ago
    Maybe even if not! I didn't care that much for zsh but I love fish.
  - reificator 9y ago
    I love zsh, but am not a huge fan of fish. Lots of non-standard things that don't play nicely with existing workflows. I prefer bash/zsh/etc because of the ecosystem around them. If I wanted to throw that away and start from a different base I'd probably use Powershell or something like it to be honest.
  - oboopfmlrmnmn 9y ago
    I love zsh, but abandoned ship of fish long ago.
  - CJefferson 9y ago
    I find fish interesting, because I thought it is what I wanted (throwing away the pain of sh syntax), but now I just have to keep switching between sh and fish and I keep forgetting which is which. I have to write too many scripts for other people, and I can at best assume they have bash. I've gone back to bash, might try out zsh.
    - StavrosK 9y ago
      Why not just write scripts in bash (or, hell, Python?) and use fish as your shell?
fapjacks 9y ago
My first shell was ksh on a DEC Unix many years ago. That was the first scripting I ever did.
alxlaz 9y ago
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.
- throwaway2048 9y ago
  its not a fork of ksh, its a fork of an open source ksh clone called pdksh that predates AT&T ksh open sourcing, and is frankly kinda crap. OpenBSD has improved it, but compared to real ksh its lacking quite a lot, most painfully sane substrings.
  - alxlaz 9y ago
    Right. In the spur of the moment I wrote "a fork of ksh" as in "a shell (mostly) conforming to ksh' specs", which is technically incorrect -- the worst kind of incorrect.
GrumpSlverBear 9y ago
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.

nn3 9y ago

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 9y ago
> 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 9y ago
  yes i built ast quite a few times. nmake always worked fine.
  - siteshwar 9y ago
    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.
matttproud 9y ago
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.

webreac 9y ago

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 9y ago
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 9y ago
  That just sounds like (practically speaking, if not totally accurately) local scoping.
chasil 9y ago
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.