Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News

Ask David Korn About ksh And More 144

Posted by timothy from the and-his-critically-acclaimed-pop-music dept.
David Korn is the author of the famous Korn shell, ksh, which deserves consideration next to the ubiquitous bash. Quote (regarding the AT&T research group he's part of): "We don't write anything in Perl anymore, because [ksh93] has all the functionality built in." He's also an AT&T fellow, and heads up the UWIN project, which "provides a mechanism for building and running UNIX applications on Windows NT, Windows 98, and Windows 95 with few, if any, changes necessary." This is the software that allowed some crazy folks to run GNOME on Windows several weeks back as well. (And is available for no-cost personal use.) This is the same David Korn you may remember from this picture. I met him at a recent NYLUG meeting when he spoke about the Advanced Software Technologies collection of tools, now Open Source, and he graciously agreed to field questions in the usual Slashdot interview style. So please leave your questions in the space below --1 question per comment, please -- and Korn will get back to you with answers in the near future.
This discussion has been archived. No new comments can be posted.

Ask David Korn About ksh And More More

Ask David Korn About ksh And More

Comments Filter:

  • pdksh... (Score:3)

    by mirko ( 198274 ) on Friday January 26, 2001 @06:09AM (#479827) Journal
    Do you collaborate (or plan to) with the pdksh development team ?
    --
  • It's already been done. Do a search for "Korn shell" and Windows in your favorite search engine and you'll find dozens of KSH compliant shells for windows. KSH is the official shell of the POSIX standard so you want posix, you need korn.

  • korn (Score:1)

    by Anonymous Coward

    How does it make you feel that a shitty rapcore band is using your name?

  • Thanks, man - you rock! I agree, ksh is one of the best-thought-out command-line shells. I'll try this stuff on bash tonight, it works on ksh.

  • I'm currently using version M 1993-12-28 j on a FreeBSD 4.2-RELEASE system, compiled from the sources available at AT&T.

    My question is about ksh's regex capabilities. You mention that you don't have a need for Perl anymore due to expanded features in ksh. I have found the only area in which ksh seems to need improvement is in it's regular expression syntax, which differs greatly than the "norm" (if there is such a thing) in the UNIX world.

    Are there any plans to move towards a more POSIX-style for regular expressions, like those found in grep and Perl?
  • > The problem is that both are designed with large numbers of synchronous interfaces. Windoze has an excuse in that it is based on W3.1 where everything was synchronous,

    NT 3.51 (I believe) batched GDI requests up, to prevent the heavy performance of user mode->kernal mode switch.
  • Hmm...

    IMHO, Unix is fluid enough not to be holding up progress. Most of your modern Unices have a plethora of features and hooks which wouldn't be found earlier, particularly in userspace. While some completely new paradigms exist (such as exokernels), even these can (via userspace libraries) be made to expose a Unixlike interface to applications.

    Consider, for instance, the relatively recent introduction of threading (both userspace and kernelspace); checkpoints (in userspace); component object models (userspace); ACLs (both); etc.

    While there most certainly are revolutionary ideas out there (hence Plan 9 and The HURD), these can still be edged into "unixlike" operating systems, retaining application compatibility and decreasing the amount of retraining necessary on transition. However, they will be even less "your father's Unix".

    I'm not current on OS research -- so take this with a grain of salt -- but I expect that Unixlike OSes will be around for quite some, even if they lose much of the appearance and limitations of the original. Improvement, that is to say, will be incremental rather than revolutionary. 'Twill still happen, though.
  • > Do you have any thoughts about why the shell concept has not caught on with other operating systems? I'm thinking of NT and Win2K in particular,

    Guess you have never heard of 4NT [jpsoftware.com] and 4DOS [jpsoftware.com] (Sorry for sounding like a commercial, but I've was using 4DOS since MSDOS ver 5, as a command.com replacement and NEVER had any problems! Games, Qemm, etc all worked perfectly back then. (History Trivia: Norton Utilities licensed a version and called it NDOS)

    I stopped using 4DOS about 3 years ago, when I switched over WinNT 4, and found 4NT.

    4NT does file-name completion better then any shell I have seen. Everytime I hit tab, it completes the NEXT filename to match. Shift-Tab does the previous match.

    i.e. directory
    abc
    ade
    adz
    foo

    I press tab and it puts the first filename on the command line. I press it again, it cycles to "ade", pressing again "adz", and pressing once more, puts "foo".
    If I start with "ad", then press tab it complets "ade" (like bash), I press tab once more, and it goes to the next match, "adz"

    Can BASH / KORN be configured this way ?

    P.S.
    Filename completion IS in the default shell "cmd" of Win NT4 and Win NT5 except the idiots at M$ DISABLED it by default! Search the registry for "CompletionChar" and set it's DWORD value to 9 (which is the TAB key)
  • Strange assertion - bash 'seeming' to be the standard UNIX shell. Since it isn't available by default on many (or is that any?) commercial UNICEs.

    My bad. :(

    I think I interpreted the line in one of my Bash tutorials that said something like, "Bash is available on my Unices, and is the default on some of them" to be, "Bash is the default on many of the available Unices."

    So it may be fair to reflect on what is missing from ksh that is in bash - things like PROMPT_COMMAND for a start.

    I think the question is still valid, my misinformed comments notwithstanding. If Bash is a superset of features from ksh, then what still makes ksh an appealing shell to use? What distingishes ksh from other shells that have similar features and/or functionality?


    --
  • Its flamebait because you were starting an OS war thread instead of discussing Korn shell issues.

    The title of the article is Ask David Korn About ksh And More . Korn has a lot of experience with the internals of both, and trying to get the different philosophies to cooperate with each other under one OS. Seems like a fair question directed to the perfect person...

  • I realize that this is a mightily pro-Linux sight, but I still can't see refering to the bash shell as ubiquitous. In fact, outside of Linux I've never seen it as the default shell, and don't necessarily even see it installed. In Solaris, HPUX, AIX and such the ksh or csh are certainly the standards.

    My 2 cents.

    Scott

  • 4NT does file-name completion better then any shell I have seen. Everytime I hit tab, it completes the NEXT filename to match. Shift-Tab does the previous match.

    Of course zsh does that!

    setopt automenu

    (I think bash does as well.) Believe me: zsh (and bash) is much more powerful than 4NT. I use both on NT (zsh under cygwin). When I moved from DOS/4dos to unix I just couldn't believe what zsh was capable of.

  • Graphical dtksh, zend, standardizing on ksh93, rpm (Score:3)

    by emil ( 695 ) on Friday January 26, 2001 @07:45AM (#479839)
    1. Since the code to Motif is now free and open, is there any possiblity that dtksh, the ksh93-compliant CDE shell with Motif extensions will be open-sourced? Novel wrote it; will they give it away?
    2. Any possibility that you could leverage Zend from php? Or what would it take to implement a dbi-like SQL layer for ksh?
    3. Under Solaris and HP-UX, ksh88 is installed in /usr/bin/ksh, ksh93 is installed in /usr/dt/bin/dtksh, but the default shell is the "Posix" shell, a superset of ksh. Is there any hope of getting this mess straigtened out?
    4. Will I ever expect Red Hat to include an RPM for ksh93? Or would you consider merging with Bash?
  • First of all: you're one of my heroes. Now my question: Do you feel like that ksh really has a future as far as the development of it? I've always thought that zsh is ksh on LSD or something. Do you feel like there is anything "new" to do with it? or has bash and zsh, etc done it all?
  • Darn... you took my question already. ;) If I may clarify a little, a friend of mine told me this story and I'm really interested to know how true it is:

    Microsoft was doing a presentation about the upcoming features of Windows NT 5.0 and the presenter enthusiastically told about how the DOS shell was borrowing many features from ksh. He went on to explain this features and someone in the crowd tried to get the presenter's question. The individual asked a few pointed and technical questions, hinting as some doubt if MS could do what they planned. The presenter "pooh-poohed" the questioner and basically told him the MS engineers would work out the details and that the questioner had nothing to worry about.

    At this point, another person stood up and proclaimed, "Do you know that he is David Korn?"

    Anyhow, this is the version I know of, and I found the story to be a riot. It is probably off base, but a little more clear than the original poster's description. I'm *really* curious to know how much of this is true.

  • According to The Open Group, there is no such thing as a "UNIX-like" system [unix-systems.org]. I personally use the term "nixclones" for GNU systems (GNU/Linux, Cygwin) and BSD systems. Or is that also a trademark abuse?
    Like Tetris? Like drugs? Ever try combining them? [pineight.com]
  • Actually, that brings one of the main features that works in ksh but not in bash or pdksh, which is:

    some_command |read varname

    For whatever reason, varname is never set in bash or pdksh. What makes this particular operation so difficult? Do most shells execute the read after pipe in a sub process?

  • One feature I miss in bash that's in ksh is
    cd from to

    It works like this: suppose you're in a directory
    /home/splante/ec/src/com/insightsys/ede/abcd
    but you have a parallel directory structure to
    'src' called 'test' and you want to cd to the same
    dir there--i.e. to:
    /home/splante/ec/test/com/insightsys/ede/abcd

    In ksh you just type:
    cd src test </blockquote>
    and it takes you there, printing the full directory you are now in.

    I find this a hard feature to live without, so I have this in my .bash_profile when I use bash:

    function cd()
    {
    #there are options on cd in bash2
    cdopts=""
    while [ "$1" != "${1#-}" ]
    do
    cdopts="${cdopts} ${1}"
    shift
    done

    if [ $# -eq 2 ]
    then
    pre=${PWD%%$1*}
    [ "$pre" = "$PWD" ] && { echo "cd: bad substution"; return 1; }
    post=${PWD#*$1}
    newdir="${pre}${2}${post}"
    [ -d "${newdir}" ] || { echo "cd: ${newdir}: no such directory";return 1;}
    echo "${newdir}"
    #echo builtin cd $cdopts "${newdir}"
    builtin cd $cdopts "${newdir}"
    else
    # echo builtin cd $cdopts "$@"
    builtin cd $cdopts "$@"
    fi
    }

    With this, bash can do it too. Of course, I have
    to copy it onto every system where I use bash
    (mostly Linux).

    Bash has some nice things too, though.
  • You may be right about having to be logged in.But if you could tell me how to get a Windows box (any flavor) installed without the GUI or to boot to a console from which I can do almost anything I want and then only start the GUI when I want it please let me know. Why should my disk space have to be used for a ever growing swap file when most other OSes happily use a partition that the usage of grows and shrinks as needed. You know a why to roll your own kernel under Windows? I would really like to have this information. Granted I can not install sound drivers but the support for it in the kernel is still there (sound might be a bad example) but the point is I can not configure my own kernel. I'll grant that sometimes support for long file names work but I can not everytime cd to a directory with lonf filenames without resorting to the 8+3 hack. I know many people who have the same issue. Does not work right even with a hosts file, try it.
  • I don't know about "world's best GUI"...and KSH is inherently CLI-oriented (and thus, not much related to whatever GUI you want to use). However, Mortice Kern Systems has been selling various incarnations of its "MKS Toolkit" since the mid-80's. I've been using their Korn-Shell as my preferred CLI under MS-DOS for over 15 years. Their version for Windows/NT is pretty good, too.
  • I hate to say this, but none of the shells are okay for web programming. Never forget this, "use the right tool for the job to be done.", just because one loves assembly programming doesn't mean it should be used for webprogramming. strong interpretted/scripted programming languages like perl/python/php are what you should look at. If ksh was fixed up to be good enough for webprograming, someone will soon request for a database library! yeah, for a shell...

  • There is a length limit on the "Subject" field of Slashdot posts. If the poster had attempted to use the subject you suggest, he would have been stuck with the following:

    What functionality or code in ksh are you least pr
  • How do you prepare ksh? I was trying to fry some up the other day and I think I added too much paprika. It tasted, ya know, so-so so I added butter. Well then hell things really got bad. I couldn't tell my ksh from by bash. It all tastes like csh.

    ----

  • What functionality or code in ksh are you least proud of, Sir?

    Where is the Grammar Nazi when you need him?

  • I'm still partial to 'ed'. Quick, easy (since I learned all it's commands before vi was invented), and lightweight. Also, despite claims to the contrary, the command-line mode in vi *cannot* do everything that ed can - multiline commands, for example.
  • Why have the Bell Labs originated shells, Mashey, Bourne and Korn been named after their main programmers? Other than awk programmer names don't show up in the names of programs developed at Bell Labs. Other shells developed outside Bell Labs tend to be named after some design goal.
  • Moderators:

    Moderate this guy up!!!!
  • With Kiem Phong Vo and others, you have espoused a number of library design principles (e.g., use of (stackable) disciplines and proper exception handling) and used them to great effect in sfio and other libraries. Sfio, in particular, is just so much better than stdio that every time I use the latter I cringe.

    Unfortunately, these libraries seem to have not been widely adopted by the free software community since they were opened. (Perl can use sfio; other examples?) What do you think is needed to change that? Licensing? Perhaps distribution in the base packages of the free operating system distros? More documentation/tutorials/examples? These packages have their own auto-configuration feature test tool (iffe) and build scripts that differ in the details from the "./configure ; make ; make install" procedure common to much free software. Would it be helpful to convert them to use autoconf, for example?

    It seems a terrible shame that more programmers are not exposed to the library construction and reuse principles in Sfio, Cdt, Vmalloc. If these libraries were in everyday use, we'd probably see more code written in that style.
  • Actually...

    I have a suite of scripts and functions that I recently implemented to handle MS-SQL Server/7 from KSH. I currently do quite a bit of automated database processing from KSH.

    I've just finished a (less satisfactory) package for dealing with Oracle, too.

  • Do you have any thoughts about why the shell concept has not caught on with other operating systems?

    Probably because Mac OS and Windows are designed around an assumption that newbies are very afraid of a command line.

    I'm thinking of NT and Win2K in particular, but it seems to be true in general.

    Bash and Fileutils have been ported to DOS [simtel.net] (you'll need at least bsh204b.zip, fil316.zip, and txt20b.zip to get a useful shell). So has a lot of other GNU software; start with DJGPP [delorie.com], the DOS port of GCC.

    Install Red Hat Cygwin [redhat.com] and you get Bash, GCC, and other things you may be used to on GNU/Linux, BSD, or UNIX systems.


    Like Tetris? Like drugs? Ever try combining them? [pineight.com]
  • I'm not *that* young and have been using unix since before Linux 1.0, so I'll tell you why I run out and install "bash" to replace ksh - Reverse ISearch. Ksh has its own version (which resembles many other CLI's like matlab) but readline's implementation is just more usable. Thats it.

    I still script in ksh, no point in being a bigot about it.

  • IIRC, there's also a dtksh, in which all of the CDE controlling scripts are written. It seems to be ksh with some GUI-ish stuff built in (kinda like Tk).
  • > zsh (and bash) is much more powerful than 4NT.

    Yeap, I know. I just got used to the 4NT %@ commands and have a hard time converting over to another shell.

    Got a link for zsh? That shells sounds kind of interesting.
  • csh is NOT the default shell in Solaris, sh is.


  • This doesn't have anything to do with the ultra-cool ksh, but I'd thought I'd mention it: this message [gnu.org] is the announcement of removal of support for GCC running under UWIN. This decision came direct from RMS [gnu.org] and generated lots of discussion over the next several days concerning legal-but-not-political decisions [gnu.org].

  • Ahem:
    jr:merlin% pkginfo | grep bash

    system SUNWbash GNU Bourne-Again shell (bash)
    jr:merlin% uname -a
    SunOS merlin.scms.rgu.ac.uk 5.8 Generic sun4u sparc SUNW,Ultra-1
    Bash is shipped in Solaris 8, along with zsh (my personal favourite) and some other open source goodies.
    --

  • On my Solaris x86 system, here are the sizes for some of the ksh-type shells:

    -r-xr-xr-x 2 root root 215304 Jan 5 2000 /sbin/sh
    -r-xr-xr-x 3 root bin 167168 Jan 11 00:04 /usr/bin/ksh
    -r-xr-xr-x 1 bin bin 651888 Dec 2 1999 /usr/dt/bin/dtksh

    But wait, ksh93 (which is sort of dtksh) supports libraries loaded at run time, so the size can be deceptive.

    I've heard that sash is much more appropriate for a linux-floppy environment.

  • AFAIK it's just there. I've believe that both tab and esc-esc work for it. I know what you mean about the HP-UX thing - ll everywhere :)
  • How do you address the ever changing future of the microsoft product line, as far as UWin is concerned?

    [For example, MS .NET probably is not going to let you host your stuff there, even if you wanted . . .]

    Given the variety of problems MS has had with their servers over the past few days, what is your opinion of the future/workability of that approach compared to your own?

  • Why Only Unix/Linux? (Score:4)

    by north.coaster ( 136450 ) on Friday January 26, 2001 @06:22AM (#479866) Homepage

    The "shell" has been a key feature of Unix/Linux for over twenty years. The concept of having the freedom to use a different shell is clearly popular and important among users. Do you have any thoughts about why the shell concept has not caught on with other operating systems? I'm thinking of NT and Win2K in particular, but it seems to be true in general.

    north.coaster

  • doing a 'bash-mode', where those of us who prefer bash on the command line would be able to have easy bash-style commands, while still retaining the ksh scripting features?
  • Come on kiddies, you're showing your youth :-) ksh existed long before bash.

    "bash is the default shell on Unix?" On Linux, yes, on Unix, no.

    Most of the cool bash-isms (such vi and emacs editing modes) were straight from ksh. Bash was a free clone of ksh, with a bunch of other stuff thrown in.

    I get a bit of a kick out of these Unix youngers, forced to use Solaris, run out and install bash, not realizing /bin/ksh does most of the same thing. (The main reason that Unix youngers will just plain not use ksh, is lack of arrow key support. But no *real* Unix user would think of using arrow keys. Why not just find a "notepad" and Windows Explorer clone, or go back to Windows :-)

    bash is to ksh as Linux is to Unix. A newer, cooler, free version of an great thing.

    -me-

  • How do you make a program work like the cd command? I mean a separate process, not the kludges that shells use.
  • Is long filename support not a kludge on FAT(12|16|32), even on NT/W2K? Ok, few people need to use FAT16 or FAT32 but lots still need FAT12.

  • Korn (Score:1)

    by bendawg ( 72695 )
    What's your take on the rock group Korn? Do you love them, hate them, or wish they would stop using your name?
    Do you ever plan on doing a deal where Korn is the official band of ksh, or ksh is the official shell of Korn?
  • the entire GUI can be controlled from the keyboard, if necessary.

    While not quite true on Windows, this is true for xfree: press Ctrl+Shift+Numlock and use the numpad keys to navigate. Then you can even do things like freehand area selection on the GIMP without a mouse.


    I guess you probably meant keystrokes for menus etc in Windows, though. GNOME+icewm passes this test too (without having to use the numpad pseudomouse).

  • UWIN and Cygwin (Score:3)

    by Lumpish Scholar ( 17107 ) on Friday January 26, 2001 @08:06AM (#479873) Homepage Journal
    How would you compare the UWIN and Cygwin [cygwin.com] projects?
  • I've had trouble with ^R. The closest I've come is:
    !cmd:p
    [uparrow] ... then edit.

  • ksh93 as a programming language? (Score:4)

    by Lumpish Scholar ( 17107 ) on Friday January 26, 2001 @08:09AM (#479875) Homepage Journal
    What are some of the differences between ksh88 (which I think of as comparable to bash or the Posix shell) and ksh93, that makes the latest KornShell as good or better a language than Perl?
  • That's fantastic. Thanks for that function.
  • Actually, no, you get bash, tcsh, and zsh even if you never touch the suplement CD. Also Perl and Apache.

  • You mean this one? (Score:4)

    by robinjo ( 15698 ) on Friday January 26, 2001 @08:12AM (#479879)

    I've been attending the USENIX NT and LISA NT (Large Installation Systems Administration for NT) conference in downtown Seattle this week.

    One of those magical Microsoft moments(tm) happened yesterday and I thought that I'd share. Non-geeks may not find this funny at all, but those in geekdom (particularly UNIX geekdom) will appreciate it.

    Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enough integrated.

    An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.

    The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.

    The questioner again asserted that the MKS shell was not very compatible and didn't do a lot of things right that are defined in the KSH language spec.

    The MPM asserted again that the shell was pretty compatible and should work quite well.

    This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (David Korn is the author of the Korn shell)

    Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence. So, what's a body to do when Microsoft reality collides with everyone elses?

    ---Lisa

  • Probably because Mac OS and Windows are designed around an assumption that newbies are very afraid of a command line.

    Um, in case you haven't watched 99% of computer users rcently, I might remind you that that's a competely correct assumption to make. Any efficiancies gained from the command line batch processing are immediately lost when you consider the time taken to learnt to perform such functions. Rather than understand hwo to manipulate a series of around thirty of so widgets, the user must understand hundreds of commands, their relation to each otehr, and their various paramets, which are generally non-standardized across most Unixes.

    Just making a small point to remind y`all that GUIs remain the best interface for the majority of computer users - just as common cars [rather than custom hotrods] remain trhe best type of vehicle for drivers. Because most drivers aren't mechanics.

    Maybe that might prompt one the the GUI filemanagers to be capable of recursively changing permissions.

    On the topic of Windows command line interfaces, while extremely limited compared to Unix, tab completion in W2K for directories with spaces in them works much better than most Unix shells. In Unix spaces can be escaped with backslashes or quotes. But the default tab expansion uses backslashes - which makes the directory much less readable and [if there are more than two spaces, quite common for many word processed documents] often expans the filename way off screen.

    The windows cd can also do some nifty tricks. If you cd to a directory with a space in it and do not escape the name [Eg, `cd Program Files'] it will look at the unknown parameter `files' see if any directory called "Program Files" exist, and change into them accordingly. You can also use `cd ...' to ascend 2 directories, `cd ....' to go up three, etc.
  • X has problems (and so does Windows) but your description is a common misconception.

    Context switches are a problem. But the difference is not that X has 2 (client->kernel->server) and Windows has 1 (client->kernel).

    The problem is "synchronous" interfaces, where you make a call and that call, besides doing something to the screen, returns a value. This actually requires 4 context switches on X and 2 on NT according to your design.

    What is needed is non-synchronous or stream-based interfaces. In this case all the things you want to draw on the screen go into a buffer and are eventually flushed. This has the potential of making the number of context switches per operation .001 (note the decimal point) or smaller!

    With such a design the overhead of not putting the server in the kernel is miniscule, and you get all the advantages of making it user level.

    The problem is that both are designed with large numbers of synchronous interfaces. Windoze has an excuse in that it is based on W3.1 where everything was synchronous, but X was designed as a server, and they really had no excuse for doing stupid things like requiring a round trip to allocate a color or to set the current font.

    I do hope that X will be replaced someday, like soon, but we should design it right. Hacks with memory mapping and direct rendering and kernel modules are nice, but none of them come close to the win you will get with an interface that is designed to be piped. The problem is that any such interface is going to incompatable, it is impossible to emulate a synchronous interface atop an async one.

  • ksh was a nice enhancement, but it was proprietary for too long, and I think there is little reason to prefer it over bash now. For heavy-duty scripting, ksh may still be slightly better than bash now, but for those applications there are better alternatives: Perl, Python, Tcl/Tk, etc. In fact, for a while, ksh was trying to go for the scripting space that Tcl/Tk was in (including dynamic loading and widgets), and in that area, it was never competitive with Tcl/Tk.
  • Tom Morello from Rage Against The Machine graduated from Harvard Law School before turning to a career of music and thuggery.

  • ksh today (Score:4)

    by Y-Leen ( 84208 ) on Friday January 26, 2001 @06:27AM (#479884)
    During the design of ksh, were you limited/influenced by computer hardware and consumer market?

    Given the chance to completely redesign ksh for today's higher spec mahines and the current consumer base, what new features would you include?

  • True Story? (Score:5)

    by travisd ( 35242 ) <travisd@[ ]as.net ['tub' in gap]> on Friday January 26, 2001 @06:27AM (#479885) Homepage
    Was the story about you embarrasing a Microsoftie at a conference true? Specifically, that he was insisting that their implmentation of ksh in their unix compatibility kit was true to the "real" thing and trying to argue the point with you. The argument ended when somoene else finally stood up and informed the speaker who he was arguing with.

    Just curious...

  • You can read about it here [cs.mun.ca].

    Here's an extract regarding its strengths:
    pdksh's strong points are:
    • its free and quite portable - you should be able to compile it easily on pretty much any unix box.
    • the vi editing mode is better (IMHO) than that of ksh88 or ksh93 (command/file completion using tab (optional), less buggy).
    Its weak points are that there are still a few differences from ksh88 (the major one is that `echo hi | read x' does not set x in the current shell - the read is done in a separate process). See the NOTES file in the distribution for more details.

    I do believe that you could both benefit from such a collaboration and BTW, I wonder if you plan to open source ksh ?
    --

  • Two simple questions... (Score:3)

    by w00ly_mammoth ( 205173 ) on Friday January 26, 2001 @06:56AM (#479887)
    Unix was a system invented decades ago. Most software becomes obsolete after 5 years. This has not been the case with unix. Why is it still here?

    A corollary - is unix holding up progress? If a brilliant new system were to be written that overthrew the establishment (like unix did in its day), it would need the momentum of people supporting it. Such a momentum isn't possible when the hacker community continues to support the well established unix way of thinking. Does this in some way impede the appearance of a completely new paradigm (like unix was in its day...)? What would be the conditions that could create such a new system? After all, it's unlikely that unix will be the research OS of choice for decades or centuries - it will have to give up at some point.

    w/m

  • Kind of a shell question... (Score:4)

    by update() ( 217397 ) on Friday January 26, 2001 @06:28AM (#479888) Homepage
    There's a lot of squabbling in the Linux world about how the Unix mentality of small apps communicating through standard input/output to form a pipeline should be maintained in the new whiz-bang, GUI environments. Do you think that it can/should be done? What should be the most important considerations for such a messaging system and how should a standard be established?

    So Korn (the band) drinks Coors Light [att.com]? I might have suspected...

  • I see alot of shell development going to improving scripting features. Perhaps designing languages is "sexy".

    But what about improving interactive features to make the CLI less user-hostile? Tab filename completion, searchable histories, that sort of thing. And I'm sure there are undiscovered innovations. AFAIK none of the *IX shells has the interactive features of 4DOS [one-step searchable visually modifiable history].
  • I'm going to address your concerns in backwards order. Win 9x's GUI many people kind of halfway know it it still sucks. I run Gnome + E on my Linux box (Debian Testing) I can get to almost any application that I have from anywhere on my desktop by clicking on of my three mouse buttons. This as opposed to Windows where I have to go to the start button and browse through a menu or go to My Computer. May not seem like much but when you really use your machine those few seconds over the course of a day really add up. Everytime I have to use a Windows box I would kill for a virtual desktop. In short the Windows GUI sucks just more people know it. Design and implementation problems with W2K and NT. First of all there is the fact that in order for any services to be running the GUI has to be up and you have to be logged in as a user of some sort. If you don't understand why this is a problem maybe you should spend some time thinking about it in terms of resources and security at the console. Number two of a very long list. In NT (not sure about W2K here) the swap file (partition if you have it on one) can only grow it can not shrink. Problem? I think so. This next one is a bit unfair but still a problem with the implementation. It all still runs the same god damned kernel. If I don't need something (sound comes to mind) I can't take it out. Also the directory structure and the naming scheme. Support for long names is still just a hack on top of a basic 8+3 naming rule. If you have not had this fact cause you problems or at least waste your time you have not really used Windows. Also what the hell is the deal with drive letters. Is it not easier to just have everything in one tree. And as far as a W2K implementation problem try this. Put a earlier Windows box, Unix, Linux, *BSD, whatever on your network. Give it a static IP address. Boot it and pull out the network cable. When it gets back up ping the hostname. It still knows the IP address that you wanted it to have. Try the same thing with a W2K box. It does not know it's static IP anymore. This causes problems with many normally networked apps in a standalone situation. This is just a short and incomplete list of problems.
  • I've almost never see the FPATH variable mentioned by ksh users but as a programer/scripter it's one of my favorite features. Would you discuss the reasoning behind it?

  • Mac OS X is a "unix-like" OS
  • In solaris 8, bash is shipped in a supplement cd, along with kde, gnome and other freeware utilities.

    I do not believe that sun 'officially' supports it.
  • >Its flamebait because [the poster was] starting an OS war thread instead of discussing Korn shell issues.

    Yeah, this thread's s'posed to be about shell wars, not OS wars :-)

    C shell considered harmful! [landfield.com]

    (Actually, in all seriousness - I really like that "Csh considered harmful" - and the Korn shell rocks. I grew up on SunOS 4.x and csh/tcsh (with Bourne shell for scripting) and was led to ksh by a clued manager in my first job after graduation who said "Hey, check this out, they even say Sun might make this the standard shell someday instead of that C shell".

    Been addicted to it ever since. First thing I do is make /bin/ksh my default shell. If it ain't there, I put it there.

  • I, for one, have been using the Mortice Kern System's kornshell and UNIX-style utilities (MKS Toolkit) on MS-DOS, and now Windows/NT, since the mid-80's. The Korn-Shell is definitely my CLI of choice, and one of the best scripting languages I've encountered. Interestingly enough, when Microsoft still sold Xenix (as part of its attempt to fragment the UNIX community, I think), the best shell for it was also produced by MKS. Xenix didn't ship with a Korn-Shell, just a Bourne-Shell and C-Shell. I started out with the Bourne Shell under UNIX v6, and loved it. The Korn shell is, IMHO, just a (significantly) improved Bourne shell.

  • Check out "Korn meets KoRN [kornshell.com]"

    The guy actually has a copy of ``The New Kornshell: Command and Programming Language'' signed by KoRn members David Silveria, Fieldy and Munky.

  • "After all, it's unlikely that unix will be the research OS of choice for decades or centuries - it will have to give up at some point."

    It's also unlikely that autocatalytic sets of amino acids will rule the biosphere for decades or centuries or millenia or billions of years...

    UNIX is not a crystal. It changes. It adapts and evolves. It's not just a four letter word, kiddo.
  • >The main reason that Unix youngers will just plain not use ksh, is lack of arrow key support. But no *real* Unix user would think of using arrow keys.

    You just described my "first time" with /bin/ksh, having been raised on /bin/csh and /bin/tcsh in 1990-1992.

    As soon as I was shown "set -o vi", I never looked back. If you know how to use vi (or emacs - you can "set -o emacs"), you'll never use the arrow keys again in any shell.

  • I've got a somewhat similar story, actually. I randomly met Larry Ewing recently. For those new to the Linux world, this is that guy that, among other things, drew THE Linux penguin that you still see pasted all over the web. The conversation went something like this...

    Me: "So, you do a lot in the Linux world?"
    Him: "Well, you know that penguin? I was the one who drew it."
    Me: "Oh, you're Larry Ewing."
    Him: "That's right."
    Me: "Dude, that penguin is *way* over used."
    Him: *shrugs*

    ...I kinda felt bad afterwards, because he seems like a nice guy. I *was* pretty jazzed to meet a "name" in the Linux world. And it's not his fault that his art is overused. Still, I just had to say it. :)

    --Lenny

  • As soon as I saw your name, I recalled the story that made the rounds several years ago about ksh compatibility by MKS's Korn shell and Windows (see end of post)...

    My question:

    As I see it, one of the big problems that continue to affect the Unix community today is that each OS vendor customize Unix in some peculiar/exclusive way.

    I can't recall anymore, but I think I ran into the problem with ksh being significantly different from Solaris with Dynix/ptx.

    Certainly, there's a lot of shell-scripting out where where platform-specific behavior is written in each script. And the shell-command tests to identify the platform were rather yucky.

    How, then, do shell's compete against PERL or Java where part of the goal is to hide almost all of the OS-specific quirks behind a layer of abstraction? And, (assuming my memory of ksh being "framgented" across platforms is correct) has ksh "defragmented" with the newer versions?

    The lead article says that ksh now is so complete that you don't need PERL anymore. But do these ksh script still have to have OS-dependent sections?

    Thanks.

    Here is the story from William Birch (which I grabbed out of the Google Cache [google.com]:

    I've been attending the USENIX NT and LISA NT (Large Installation Systems Administration for NT) conference in downtown Seattle this week. One of those magical Microsoft moments(tm) happened yesterday and I thought that I'd share. Non-geeks may not find this funny at all, but those in geekdom (particularly UNIX geekdom) will appreciate it.

    Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enou gh integrated.

    An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.

    The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.

    The questioner again asserted that the MKS shell was not very compatible and didn't do a lot of things right that are defined in the KSH language spec.

    The MPM asserted again that the shell was pretty compatible and should work quite well.

    This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (David Korn is the author of the Korn shell)

    Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence.

    So, what's a body to do when Microsoft reality collides with everyone elses? Next topic for demonstration, please...

  • My main reason for preferring the Korn-Shell to Perl is familiarity. I use ksh as my main command-line-interface (CLI), so it is almost second nature to me. I am probably as close to a Korn-Shell "guru" as anyone this side of Mr. Korn, so I'm definitely prejudiced, here. However, I generally find it easier to "hand off" a shell-script to moderately technical users, than a Perl script. It's just easier for them to read and understand, because they use many of the commands every day.
  • can't NT format an NTFS floppy anyway?

    Dunno, but since the purpose of floppies is interoperability, for some circumstances that could be as useless as me formatting a floppy ext2. Sure, I agree floppies *should* be legacy.
  • Before I had ever used any OS on the PC but MS-DOG, and all I used my XT for was dialing up Fidonet BBSes at 1200 baud with QModem and reading QWK mail with SLiMeR, I considered a system unusable if JPSoft's 4DOS wasn't installed to replace DOS 3.3's command.com. NDOS was also acceptable.

    I vaguely remember a 4OS2 shell as well, and I know they've released 4NT.

    There are also replacements for Windows Explorer, such as LiteStep. There were replacements (most of them sucked) for progman.exe.

    Anyway, my point is that it may not be as popular as it is in the unix world, but you certainly do have the freedom to change the default shell under M$ OSes, and you always have.

  • Re:Why? (Score:1)

    by skt ( 248449 )
    Yeah right. You and I both know that the Windows 2000 "mount" feature is a joke. I actually just found out about it a few weeks ago. It turns out that there is even a >5 step wizard that guides you through the whole mount process, heh. I still haven't been able to figure out how it works yet as it isn't very intuitive.

    And on top of that, Windows doesn't have any support for symlinks. Huge limitation IMHO, I guess we'll have to wait for whistler for another "new feature" that is nothing more than a crude hack. Oh well, I'm getting used to them now. Windows 2000 now has a telnet service so that you can "telnet to your win2k box". Wow, what will M$ think of next?

  • What functionality/code in ksh r u least proud of? (Score:4)

    by segmond ( 34052 ) on Friday January 26, 2001 @06:29AM (#479905)
    It is very hard to find a programmer who is completely satisified with his code. No matter how happy she is with it, there is always that part which she wishes to improve. As far as ksh is concerned what is it that you wish you didn't do, can improve?

  • Jed (Score:1)

    by Ka0s ( 134504 )
    JED [mit.edu]!!!!
  • Would someone please tell me why the above is flamebait? I really do not understand why something like this would be good. I do not think I threw out a insult (If I did I am most sorry). I just really do not understand and would like to know more from someone who has clearly put alot of thought into it. Why is that flamebait?
  • Comment removed based on user account deletion
  • really ... i tried solaris x86 just for shits and giggles, and when faced with a totally unconfigured ksh, I just gave up after a few days.I couldn't figure out how to set emacs editing mode to save my life. Same with BSD and that horrible csh.

    No wonder unix was going down the tubes. who the hell is going to be able to figure this out as a newbie?

    What the fuck is with these people?

    --

  • UWIN and etc (Score:5)

    by rabtech ( 223758 ) on Friday January 26, 2001 @06:35AM (#479910) Homepage
    You once said that you had to learn Windows NT because you couldn't criticize what you didn't know. What I'd like to know (as a primarily Windows programmer) is what do you consider to be the best and worst parts of both the Windows NT/2000 model and the UNIX model. What advice can you give? Also, has working on the UWIN project given you any insights that you can share with the rest of the community?
    -
    The IHA Forums [ihateapple.com]
  • This is what I was saying. X is designed to by asynchronous.

    However, besided bad drivers, there are numerous mistakes in the Xlib interface so that many of the "asynchornous" calls are always followed by a wait for a response from the server. For instance the call to register an Atom requires the server to check to see if it is registered, allocate a new number, and return it. Xlib must block until this value is returned, because the Xlib interface is a function that returns the atom.

    There is very little that can be done about this because it is almost impossible to add extenstions or change the design of the X server. I think it would be faster to use string tokens than to use the bi-directional atom mechanism. Or you could give each process it's own Atom space, with translations done by the server to messages between processes (this requires the location of Atoms in each message to be identified, which is nearly impossible). It does appear that Windoze has learned to batch requests as well, they added a GdiFlush() call. They probably also call this when you do GetMessage and some other system calls.

  • I've been an admirer of your work ever since I was exposed to it. How much of your material was inspired by earlier developers, such as Nine Inch Nails, Skinny Puppy, and Ministry?

  • Public Apology (Score:5)

    by watanabe ( 27967 ) on Friday January 26, 2001 @06:37AM (#479933)
    Dear Dr. Korn, I feel I owe you an apology, and this seemed like a great chance! I went to school with Adam at Brown. And, in 1993, my roommate, Matt Smith, woke me up at about midnight, excitedly telling me "Do you know the Korn Shell? This guy's dad wrote the Korn shell!!!" He was coming in with Adam from somewhere.

    I sort of turned over in my sleep, (I was extremely groggy), and said "I hate the Korn shell." and went back to bed. Adam never really talked to me after that, although he was polite enough to me at parties.

    So, Dr. Korn, I feel I owe you an apology. I didn't mean to disrespect your lifework in front of your son! I still can't use the korn shell, but call it fear of the unknown, please, rather than lucid comments on your code.

    Peter Vessenes, Brown '97

  • For what it's worth (and I know this is common knowledge, but I'm mentioning in it hopes of limiting the number of redundant posts in this thread...): the reason that csh/ksh ship with commercial Unices and bash ships with Linux is because csh/ksh were originally written as non-free software. The need for a free, full-featured shell led to the development of bash, as well as free workalikes of the other shells (pdksh and tcsh) for those who needed to maintain close compatibility with existing ksh/csh scripts. (although scripting in csh is a bad idea from both a security and code maintainance point of view...)

    Personally, I've stuck with bash ever since I first used it, because it combines the best features of ksh (job control, history, aliasing/substitution) along with invaluable interactive features like tab completion and emacs-style editing keystrokes. If I need to write scripts, I'll either make it Bourne-shell compatible (so it will run anywhere) or else write it in Perl (where I'm much more comfortable with the syntax).

    But even though I haven't really used Mr. Korn's shell for about five years, I'm most appreciative of the advances he's made that have benefited programmers and admins everywhere. Good work!

  • Re:Why? (Score:2)

    by Masem ( 1171 )
    One problem is that for a machine of equivalent CPU, memory, etc, developing under a unix-like environment within Windows is much faster and efficient that developing on a true unix environment running X-Windows, and much much much more efficiently than playing with the console. I've found that I can move between windows faster, and because most useful documentation is online, regardless of your opinion on them, the Windows browsers work much better here.

    I also can see it for cases where you remotely develop unix apps where the connectivity between the unix box and your workstation (in this case, a windows box), is poor. I did this when I had a dialup during school stuff. Make sure everything works well in Windows, and then transfer to unix, and double check to make sure it works; assuming the ports are true, then you have no problems.

  • about the fact that the band that bears your namesake sucks out loud?
  • Can you describe what it is to be a "Fellow" at AT&T, the work you like to focus on in that role, and how a person becomes a fellow?

    On the third part about how a person becomes a fellow, what amount of experience or qualifications does one need?

    Cheers!

  • Ksh Programming For the Web (Score:3)

    by Dom2 ( 838 ) on Friday January 26, 2001 @07:16AM (#479939) Homepage
    How do you feel that ksh holds up for web programming? I have always enjoyed programming shell scripts more than anything else, but I have always been unhappy with the shell idioms for parsing securely and correctly (the myriad of substitution operators is a nightmare to control). This is one area in which Perl has really taken the lead. How do you think shell programming could be better adapted for the web?

    Also, how do you feel about most commercial Unix vendors (and projects like pdksh) that are still shipping ksh88 as the default, 13 years later? ksh93 has many more useful features, but the takeup has been slow.

    Thanks,
    -Dom
  • This is a honest quetions. But why port Unix applications to Windows? The underlaying OS is still (IMO) *very* poorly designed and implemented so what would really be the point of running a Unix application in this environment. I would think it would make more sense to develop killer apps that will make people want to learn Unix rather than giving Microsoft the abillity to say that their platform can also run that same application. So with all due respect, keep in mind I do think you most likely know more about this then I do, what is the point?

  • Comparison (Score:5)

    by Shadowlion ( 18254 ) on Friday January 26, 2001 @06:04AM (#479950) Homepage
    Background: the only shell I've ever really used is bash. Bash has always seemed to be the standard UNIX shell (or, at least, the standard default UNIX shell), and for the most part I've always been able to do what I wanted in it.

    Question: can you engage in a little unadulterated advocacy for a moment to offer some reasons why an informed user might consider using ksh over bash or other popular UNIX shells? What does ksh provide that other shells don't? Similarly, can you give a realistic appraisal of ksh's drawbacks as compared to bash or other shells?

    Thanks.


    --
  • I heard an urban legend once about a microsoft seminar where they were announcing they they had a fully complient Korn shell available with their operating system. A gentleman in the audience stood up to tell them in exactly what ways it wasn't compliant and promptly got into an argument with the Microsoft VP. Apparently the person in the audience was David Korn. Is this true?

    =)
  • X is asynchronous. Xlib buffers the commands that are going to X, and sends them en masse when appropriate. Therefor, not only do you NOT get two context switches per operation, you don't even get ONE.

    For example, if I draw a line, then draw another line, then a third, Xlib will not only buffer those requests and send them over as one bunch, it will examine the lines to see if the operation can be converted into a single polyline operation.

    This also benefits the system in that once X starts working on the commands, it can resolve several things at once, thus increasing the likelihood that the X routines and data will be in the CPU cache. The Windows approach virtually guarantees the graphics libraries will be faulted out of the working set.

    What makes X "slow" in most people's experience is the fact that the X servers receive far less optimization than the Windows servers, esp. when dealing with commodity x86 hardware. A proper X server, optimized just as the Windows drivers are optimized, is as fast as Windows, and in cases where the card can perform operations in the background, faster.
  • I just read the ksh FAQ [kornshell.com] and I found this :

    Q6. Are any further releases of ksh planned?
    A6. Yes, we are in the process of planning for a newer version, ksh200X.
    We are interested in suggestions for new features.
    Again, most of the focus will be on scripting and reusability.

    As I believe this poll is also aimed at defining these improvements I was thinking of the following:
    Ksh is supposed to make people's life easier and I use it whenever integrating e-payment software on my servers.
    I was then wondering whether some feature that I saw in VMS could be implemented in Ksh: directory-specific profiles.
    For example, you log on and set your environment (profile) with your .profile. It'd be cool, IMHO to have the possibility (which could be activated or not whenever launching ksh) to set some .profile files in any directory so that by changing directories, one could easily update its configuration to the most relevant settings.
    This would not only apply for a user working with the prompt but also whenever launching some specific scripts that are suppose to activate some binaries or whatever else somewhere.
    This would then allow some context-sensitive programs to be automatically executed with a minimal knowledge of the environment.
    So, I wouldn't have to say to the logged user to set their environement a given way whenever working or not with some apps.
    BTW, some similar feature also exists on Acorn RiscOS [riscos.com] platforms and really makes one's life easier.
    I think this is not incompatible with Unix and may even widen its possibilities (from the user's point of view).

    Finally, here's my question: Do you want to restrict Ksh to fit a stereotypic Posix environment look'n feel or are you working to make it a real enhancement of such systems, especially in ergonomy?
    --

  • what about enhancing ksh syntax ? (Score:3)

    by mirko ( 198274 ) on Friday January 26, 2001 @06:06AM (#479966) Journal
    Ksh is quite cool as it is much more compact than bash ; here are their respective sizes on a Solaris system :
    • -> /usr/local/bin/bash -version
      GNU bash, version 2.02.0(1)-release (sparc-sun-solaris2.6)
      Copyright 1998 Free Software Foundation, Inc.

      -> ls -la /usr/local/bin/bash
      -rwxr-xr-x 1 bin bin 3157516 Jul 14 1998 /usr/local/bin/bash
    • # ksh -o emacs
      # Version M-11/16/88i

      # ls -la `which ksh`
      -r-xr-xr-x 2 bin bin 186356 Jul 16 1997 /usr/bin/ksh
    On a Linux system, these are approximately 300k for bash and 160k for (pd)ksh.
    In which direction do you plan to improve it ?
    Will you rather keep it compact or extend its functionalities regardless the volume increase ?
    This issue is quite important for me as, as of yet I am working upon some System-on-a-floppy distribution and the size appears to be critical in this context.
    --

  • So, Dave ... (Score:4)

    by Anonymous Coward on Friday January 26, 2001 @06:06AM (#479968)
    Quick question: Vi or Emacs?
  • I think you meant Linux shell. Most other Unices come with either the csh or the sh. And of course all of IBM's stuff has the ksh by default. Although the first thing I do to a new SGI or Sun box is put bash on it, it is for the most part not there by default. Although I'm very interested in the answer to your question you might in the meantime take a look at Running Linux which has a very good comparision. Of course straight from the man who wrote the shell should be very interesting.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close