OpenBSD Journal

Ask undeadly: port of ksh93?

Contributed by grey on from the orphaned discussions dept.

Charles Fisher writes: With light fanfare, the OpenBSD documentation cites The One True AWK as an example of a System V utility "rescued" and incorporated into the base OS. Why then is the Korn Shell (arguably the most powerful of the Bourne-family of shells) allowed to languish, unused by any major distribution? OpenBSD's pdksh features lack a) floating point arithmetic: print $((22.0/7)) -- 3.14285714286, b) C-like numeric "for" loops: for((i=0;i<10;i++)), c) Substrings (a="hello"; print ${a:3:2} -- "lo"), d) associative arrays (x['foo']="bar"), e) case "fallthroughs" (;&); all of these features and much more are available through David Korn's ksh93 and later. Kernighan's awk is preferred to the more powerful gawk, but Korn's true shell (more powerful than pdksh or even bash) is ignored. Is it the fault of ksh's license, sfio or sundry library usage, or audit issues? But really, is not the name of Korn a worthy addition to the names of Aho, Weinberger, and Kernighan as contributors to OpenBSD, if not for reasons of functionality, then at least for reasons of notoriety?

A bit of searching through mailing list archives reveals previous discussions of the licensing, and the lack of desire to replace pdksh in the base. That said, a few individuals appeared to be interested in creating their own port for OpenBSD several years back. While Charles' question as to why ksh93 isn't in the base of OpenBSD is obviously answered already, perhaps undeadly readers might be able to help by pointing him in the direction of anyone who might have a working port they use?

(Comments are closed)

Comments

  1. By Chavdar Ivanov (82.37.76.200) ci@spidersweb.co.uk on

    Perhaps NetBSD's pkgsrc/shells/ast-ksh is the place to start?

    Comments

    1. By tedu (128.12.75.69) on

      perhaps OpenBSD's shells/ast-ksh is the place to start?

      Comments

      1. By mirabile (2001:6f8:94d:1::1) on

        ... which was removed, because the licence and code were said to smell funny. That said, pdksh doesn't yet claim ksh93 features; the version is merely tracking ksh88 (and does that pretty well), although there are a few rough edges (but on the other hand, a few nice features as well). In my opinion, there should not be a problem for ksh93 being offered as a port - heck, even the GNU bash is offered, and it's much worse.

      2. By Chavdar Ivanov (82.37.76.200) ci@spidersweb.co.uk on

        I didn't realize it has been in the ports earlier. It is still very much in the NetBSD pkgsrc (and ofcourse one can use pkgsrc under OpenBSD if one wishes so...).

  2. By Anonymous Coward (138.88.243.5) on

    One thing seems rather clear to me: ash sucks. It appears to take more memory than bash but offers less functionality, not to mention more bugs. The BSD's ought to obsess a little less about their kernels and get their userland in order. The default shell (Korn or otherwise) would be a good place to start. And [t]csh doesn't count either.

    Comments

    1. By tedu (128.12.75.69) on

      i don't think anybody was suggesting we start using ash.

      Comments

      1. By Anonymous Coward (151.200.236.27) on

        Well, good!!!!

    2. By mirabile (2001:6f8:94d:1::1) on

      No, the default shell is still the C shell, but nobody wants you to use it. It's merely default because it always was.

      Comments

      1. By Anonymous Coward (151.200.236.27) on

        Yes, one of the more outdated things that makes BSD BSD. Who in their right mind would write csh scripts these days? Why use one shell for interactive command line tasks and another for scripting? Maybe a statically compiled interactive shell (history, commandline/environment variable/sock inventory auto-completion) & scripting shell is a bad idea, but for crissakes at least keep the syntax consistent so that it just works. Historical standards ought to be adhered to as frequently as users and programmers alike make use of bits of the original pre-4.4BSD tree and rely on dumb terminals to get real work done.

    3. By Anonymous Coward (142.166.109.218) on

      ... more memory than bash but offers less functionality, not to mention more bugs. The BSD's ought to obsess a little less about their kernels and get their userland in order ...

      Actually, I always thought much the same about bash. It uses an ungodly amount of memory while offering little more than the the pd korn shell that comes with OpenBSD. As distributed with OBSD, ksh is pretty nice. Linux migrants to OpenBSD only feel they much install bash because ... well ... they just don't know any better 8P

      Comments

      1. By Anonymous Coward (151.200.236.27) on

        bash is good for the interactive features and configurable so that if you are used to having this key do that you can change it in the config file, but I try to avoid bash-isms in scripts. For the most part though, this isn't a big problem. Surprise, even gnu monkeys can make a mature, useful program! The real sticking point are those 5% of the time situations where bash chokes on wildcard expansions of filenames with spaces, etc. Ksh appears to be an industry standard, so you would assume that the new functionality ksh offers (presumably for shell scripts, I don't use associative arrays much from the command line) would make it easier for Solaris scripts to work with BSD/Linux/etc. It seems to me that a worthy goal is to offer the best of both worlds, just not necessarily at the same time, so to speak. Taking into account that this has been tried so many times already, this ought to be a little more straightforward in that programmers know what not to do.

      2. By Anonymous Coward (138.88.101.218) on

        From top:

        PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
        699 ardvark 8 0 1724K 1156K wait 0:00 0.00% 0.00% sh
        845 ardvark 8 0 1288K 1160K wait 0:00 0.00% 0.00% bash
        843 ardvark 8 0 2512K 1896K wait 0:00 0.00% 0.00% ksh93

        Comments

        1. By mirabile (194.8.207.18) on 

          Now play around a bit:

#!/bin/ksh   (or #!/usr/local/bin/bash)
a="aaaaaaaaaaaaaaaa"
while true; do
  a="$a$a"
done

Then watch top(1) again.

Also, the GNU bash gets _very_ slow once the string's
size exceeds 16 KiB, whereas (pd)ksh shows no noticeable
slowdown before 256 KiB.

          Comments

          1. By Anonymous Coward (138.88.213.94) on

            I can see where that would be useful.

        2. By Anonymous Coward (131.202.171.91) on

          You must be using Linux? On my i386 OBSD 3.4 machine Top gives:

          29450 fluffy 18 0 372K 312K sleep pause 0:00 0.00% ksh

    4. By krh (207.75.181.241) on

      It's always seemed to me that Linux users are the ones obsessed with their kernels. I'm happy to run GENERIC; it's the recent Linux migrants who want to reconfigure and patch it.

      Comments

      1. By Anonymous Coward (138.88.101.218) on

        You can save space by taking out the drivers you don't need. Once you've tweaked your config file the way you want it (start with a copy of the GENERIC config file), all that you normally have to do to upgrade it is to rebuild your kernel with the same file. Best way to get new features, security patches, and bug fixes. Shh! Don't tell the Linux users.

  3. By tedu (128.12.75.69) on

    http://www.research.att.com/sw/license/ast-open.html too many words.

  4. By chas (12.217.90.112) on rhadmin.org

    1. I don't need anybody to compile ksh93 for me. "LDFLAGS=-s\ -static CCFLAGS=-O2 bin/package make ksh" seems to work pretty well, although production users might want to disable the experimental features.

    2. Who said anything about replacing pdksh? Korn has not made ksh88 available; therefore, pdksh would be better under low memory situations, and is preferable from a historical perspective. Including both pdksh and ksh93 in the base OS is still less space than Bash (and more power).

    3. Yes, the ports version of ksh was removed. What exactly is objectionable?

    Comments

    1. By tedu (128.12.75.69) on

      license, license, license. it has too many words, it has weird patent clauses, and it uses weird terms like "capsule". or just read the cvs commit message:
      "Remove the ast-ksh port. Restrictive, inscrutable license; weird build system; code doesn't inspire confidence; mostly broken."

  5. By Anonymous Coward (206.171.8.191) on

    Hello? Just use Zsh. Zsh is the cadillac of shells, and AFAIK can do everything ksh93 can and more (juggling and chewing gum at the same time as well).

    Comments

    1. By Anonymous Coward (206.171.8.191) on

      Okay, so zsh doesn't seem to support /dev/tcp like ksh93 does. Though, bash does include this feature.

      Comments

      1. By Anonymous Coward (2001:6f8:94d:1:2c0:9fff:fe1a:6a01) on

        zsh's defaults suck, and pdksh does /p/tcp: man mount_portal

  6. By Anonymous Coward (4.61.192.159) on

  7. By RC (4.61.192.159) on 

    It's about license and portability.  ksh88 features are in nearly every shell, while ksh93 features are not found practically anywhere else.  When I'm writing a shell-script, I want it to be portable, not just work on my own system...

>  a) floating point arithmetic: print $((22.0/7)) -- 3.14285714286

This has been handled by the inclusion of "bc" in every unix OS.  Using bc is portable, doing it the ksh93 way would not be portable.  

> b) C-like numeric "for" loops: for((i=0;i<10;i++))

A 'while' loop can do the exact same thing, just in perhaps 3 lines instead of 1.  No big loss there.

> c) Substrings (a="hello"; print ${a:3:2} -- "lo")

Currently handled with awk.  Awk also can do far far more than I'm sure ksh93 can, so the awk way is more portable, and more powerful.

> d) associative arrays (x['foo']="bar")

Another nice feature that isn't strictly needed.  It can be handled with normal variables.

    Comments

    1. By Anonymous Coward (151.200.236.27) on

      Is basic floating point arithmetic so "sophisticated" code-wise in this day and age that you need to fork() and exec() to bc? Given that most computers these days that aren't serving as door stops have fpus embedded into their cpus, I disagree with you there.

      for ((blah; blah; blah)) -- I have to agree with you there. The syntax doesn't win any points for elegance either.

      ${a:3:2} -- Yes, this is useful, flexible functionality. Unlike ${foo%somesuffix_that_got_up_mr_bournes_nose} and some of the lesser known find primaries like "-filenamedfred". Should more regex support be in a shell? Not if it doubles the size of the program, no.

      associative arrays--If just about everything starts off as a string in a shell and associative arrays aren't much harder to implement correctly than plain old numerical ones ( $yerstring[$i] -- what happens if i="notanumber"? ), then why not go for it?

      bloat issue -- Are you worried about redundant code filling up your otherwise empty swap space? Stop worrying. No one runs Version 6 anymore. Will stacks and heaps explode? Doubt it. Will your hard drive and the filesystem get a rest at the expense of a little more memory usage outside of the kernel? Very probably.

      Comments

      1. By RC (4.61.196.211) on

        | you need to fork() and exec() to bc?

        What is wrong with that? It's not as if it puts extra work on the shell-script-writer.

        | bloat issue -- Are you worried about redundant code filling up your
        | otherwise empty swap space? Stop worrying. No one runs Version 6
        | anymore. Will stacks and heaps explode? Doubt it. Will your hard drive
        | and the filesystem get a rest at the expense of a little more memory
        | usage outside of the kernel? Very probably.

        You make the same mistake several times, in thinking that I listed system requirements as a draw-back. I did not. I primarily listed cross-platform compatibility.

        Even if these features were great and incredible, you can hardly expect every other OS on the planet to adopt ksh93, and include it in the base. I know I hate comming across bash-specific shell-scripts, and I'm not willing to release more incompatible scripts upon the world myself.

        Man, I really hate the HTML-only requirement here on undeadly. Why shouldn't plain-text formatting work? Really now...

        Comments

        1. By Anonymous Coward (138.88.213.94) on

          Even if these features were great and incredible, you can hardly expect every other OS on the planet to adopt ksh93, and include it in the base.

          Hello? 1993 was ten years ago! Who is using shell scripts from 10 years ago (much less machines that are that old), and why is it so difficult for them to change a stupid shell script? Show me a system that you can't port ksh93 to, and I'll show a rubbish tip where you can get it off your hands for 5 bucks.

          Comments

          1. By Jeffrey (206.148.108.209) on http://jneitzel.sdf1.org/osh/

            Well, I have always liked pdksh.
            It is a very nice interactive shell.

            OTOH, the few times I used (or even tried to install) ksh93...
            It was really a nightmare. Then I looked at the code. Ugh, I don'tknow if I'm qualified to say anything, but the code for this shellreally sucks. No wonder it is so difficult to get it compiled, installed, and working.

            I suppose the code is just not very portable.Compared with all that the PD ksh is very much nicer.Who needs functionality..? ;)

            Personally, I use osh as my primary login shell.It's fun to use because I like history.It is perfectly scriptable to. You just have to work harder at it ;)

            We cannot forget history!
            We should all still be using V6 and V7! =)

            Comments

            1. By Anonymous Coward (138.88.200.143) on

              V5 through v7 work great when hosted on a machine running simh, probably faster than on a pdp11 with all the trimmings --which isn't saying much. Line editing? See what happens when you type "rl#m # /e#be#i#n/*". Command line history? Filename completion? That's for weenies! Vi, emacs? It's ed or nothin. More? Not likely, but perhaps you can write your own version. Think the Bourne shell is too extravagant? Use its predecessor! Have fun, and here's to your much improved productivity.

    2. By krh (207.75.181.241) on

      Dear RC,

      Please don't use <pre> like that. Thanks.

      Yours sincerely,

      krh

      Comments

      1. By RC (4.61.196.211) on

        > Dear RC,> > Please don't use <pre> like that. Thanks.

        Yes, I saw what terrible things it did only after I posted it. I will preview more in the future. I wouldn't think a forum should be so rife for abuse like this (whether accidental or intentional). Some other option would be preferred. Going through and manually escaping every single gt, lt, and amp character is tedious. Having to add all other HTML tags once any one has been added is annoying as well. This is why I don't post much...

        Incidentally... undeadly doesn't seem to like to have comments submitted through a proxy for some reason. I have to disable my filtering proxy to preview or submit comments. And no, I can't set undeadly as a site that should bypass the proxy, because the white background will burn my eyes out in short order.

        Comments

        1. By Anonymous Coward (138.88.245.33) on

          What, is this guy worried that undeadly.org is going to get rooted by you if you use illegal html?

    3. By Anonymous Coward (68.124.163.80) on

      Thanks for the informative post.

  8. By uriel (81.172.228.44) on

    My question is why don't we dump this outdated sh/csh(and derivatives) crap and use rc as default?
    http://www.star.le.ac.uk/~tjg/rc/misc/td

    There is an implementation of rc for unix with a plain BSD-like license:
    http://www.star.le.ac.uk/~tjg/rc/ This stuff is over 15 years old now, don't you think it's about time we try to start catching up with Plan 9?

    Comments

    1. By Anonymous Coward (151.200.236.27) on

      I think Plan 9 has a lot more to catch up with than OpenBSD does.

    2. By Anonymous Cheese (68.124.163.80) on

      "My question is why don't we dump this outdated sh/csh(and derivatives) crap and use rc as default?"

      There's no need to begin your question by telling us it's a question. Maybe you just like unnecessary redundancies? Some call it bloat.

      rc as the default root shell? You are full-o-bloat, and you leave your question to ambiguity? There is no need for the root account to use a modern shell; did you read that? Read it 7 times until you understand what is being said. A shell that does just the needed work for the root account is all that everyone will ever need. For everything else, create a user account, pick the shell you like (/usr/ports/plan9/rc), and give the account SUDO privileges. Making the root account useable for dorks like you is dangerous. csh is horrible, and it needs to stay that way; csh forces you to not use the root account for everyday work.

      Something comes to mind; Linux. Not that bash is useable; but can you imagine all the Loonies that never create a user account and work as root because the default shell(bash) is comfortable to use?

      Comments

      1. By Anonymous Coward (138.88.213.94) on

        Unix doesn't get in the way of a user who wants to do something stupid. That's a tradition of sorts. Why do you feel compelled to worry about what loonies/retards are doing?

        Comments

        1. By Anonymous Cheese (68.124.163.80) on

          "Unix doesn't get in the way of a user who wants to do something stupid. That's a tradition of sorts."

          I agree.

          "Why do you feel compelled to worry about what loonies/retards are doing?"

          Because if a person has the intelligence to consider using OpenBSD, then there is a chance the person can be rid of their ignorance; in this case, their ignorance is thinking that making root useable for anyone other than a knowledgeable user is The Right Thing.

          Comments

          1. By Anonymous Coward (138.88.245.33) on

            Because if a person has the intelligence to consider using OpenBSD, then there is a chance the person can be rid of their ignorance; in this case, their ignorance is thinking that making root useable for anyone other than a knowledgeable user is The Right Thing.

            Show me those dreaded command line history exploits that can be used on running shell scripts, please. Better yet, show me a patch so that everyone can benefit from a well maintained shell. This idea that code rot and a total lack of useability somehow can alter a users behavior to make things "more secure" is nothing more than a cop out. The idea of "secure by default" is to make hardening a system easy. By the same token, if you make it hard for the person who should have access to the computer to access their machine, it encourages him to be sloppy, possibly even to open up "temporary" security holes in order to make his workload smaller. Is it really that difficult to set up a useable non-root account? Well, it shouldn't be. The default shell is the default shell regardless of whether you're logging in as root for the first time or setting up another account. Should certain priviledges be devolved to users other than root, sudo as part of the default configuration? Good idea. Does that mean that the default shell shouldn't have halfway decent command line editing and a working backspace key? No.

        2. By Anonymous Coward (217.210.130.143) on

          UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. -- Doug Gwyn

          Comments

          1. By Anonymous Coward (138.88.87.217) on

            Darn tootin'.

          2. By Anonymous Cheese (68.124.163.80) on

            While we are on the topic of being clever; "K & R" suggests you avoid being clever.

            Comments

            1. By Anonymous Coward (141.156.226.54) on

              What? Show me the exact chapter and verse where they say that!

      2. By Anonymous Coward (210.50.30.21) on

        csh is great! What are you talking about? ;)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]