Slashdot Mirror
Ask David Korn About ksh And More
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.
Do you collaborate (or plan to) with the pdksh development team ?
--
Trolling using another account since 2005.
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?
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.
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...
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.
-- Solaris Central - http://w
According to The Open Group, there is no such thing as a "UNIX-like" system. 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?
Will I retire or break 10K?
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?
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...
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
Moderators:
Moderate this guy up!!!!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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 (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, the DOS port of GCC.
Install Red Hat Cygwin 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?
Will I retire or break 10K?
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).
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
This doesn't have anything to do with the ultra-cool ksh, but I'd thought I'd mention it: this message is the announcement of removal of support for GCC running under UWIN. This decision came direct from RMS and generated lots of discussion over the next several days concerning legal-but-not-political decisions.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
--
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 /usr/bin/ksh /usr/dt/bin/dtksh
-r-xr-xr-x 3 root bin 167168 Jan 11 00:04
-r-xr-xr-x 1 bin bin 651888 Dec 2 1999
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 :)
[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?
"It is a greater offense to steal men's labor, than their clothes"
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
"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-
Love many, trust a few, do harm to none.
How would you compare the UWIN and Cygwin projects?
Stupid job ads, weird spam, occasional insight at
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?
Stupid job ads, weird spam, occasional insight at
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
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.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
Given the chance to completely redesign ksh for today's higher spec mahines and the current consumer base, what new features would you include?
Just curious...
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 ?
--
Trolling using another account since 2005.
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
So Korn (the band) drinks Coors Light? 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].
Yeah, this thread's s'posed to be about shell wars, not OS wars :-)
C shell considered harmful!
(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'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:
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?
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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
Natural != (nontoxic || beneficial)
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?
We're going down, in a spiral to the ground
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!
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
about the fact that the band that bears your namesake sucks out loud?
Sig this.
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!
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?
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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.
www.eFax.com are spammers
I just read the ksh FAQ and I found this :
.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.
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
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 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?
--
Trolling using another account since 2005.
-
->
/usr/local/bin/bash -version
/usr/local/bin/bash /usr/local/bin/bash
-
# ksh -o emacs
/usr/bin/ksh
On a Linux system, these are approximately 300k for bash and 160k for (pd)ksh.GNU bash, version 2.02.0(1)-release (sparc-sun-solaris2.6)
Copyright 1998 Free Software Foundation, Inc.
-> ls -la
-rwxr-xr-x 1 bin bin 3157516 Jul 14 1998
# Version M-11/16/88i
# ls -la `which ksh`
-r-xr-xr-x 2 bin bin 186356 Jul 16 1997
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.
--
Trolling using another account since 2005.
Quick question: Vi or Emacs?