Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

David Korn Tells All

timothy posted more than 13 years ago | from the old-school-new-jersey dept.

News 118

David Korn answers! You asked the questions a little while ago, and now David Korn has kindly responded with answers (some lengthy, some pithy, all appreciated) to queries about the eponymous shell, the famous Microsoft/Korn story (in short -- yep, it's like you've heard), and proper Unix behavior. He even made his son Adam write one of the answers.

Question 1) Comparison
by Shadowlion (shadowlionc@netscape.net)

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?


David Korn: First of all, when I talk about ksh here, I am referring to ksh93 which was first released over six years ago. Most UNIX systems ship with ksh88 and most Linux systems ship with pdksh, neither of which has the functionality of ksh93.

There are two different areas of functionality in shells. First is interactive use and the second is scripting. Much of the debate about shells has focused on interactive use only. For example, tcsh is an acceptable shell for interactive use but practically unusable for scripting.

In many cases the argument over which shell is best for interactive use is based upon which key to press for completion. This is a little like arguing that Solaris is better than Windows because of location of the Control and Shift keys or that vi is better than emacs because you you can save a keystroke or two. Most popular shells have similar functionality with respect to interactive use.

It is hard to argue that ksh is any better for interaction, given all the features in tcsh and zsh. But the scripting features in ksh93 are far more advanced than any other shell that I am aware of. For scripting, I feel that ksh is more in the category of perl/tcl/python and I would like to see debates/comparisons for those languages rather than the antiquated bash/csh/etc.

I have not looked at bash for several years and some of the features I describe here might now be implemented by bash. I sent Chet Ramey, author of bash, the list of new features in ksh93 years ago so that if these features get implemented in bash, they would be compatible. Here is a partial list of ksh93 features:

  1. Associative arrays - ksh88 already supports indexed arrays.
  2. Floating point arithmetic + math library functions.
  3. Arithmetic for command similar to C and awk.
  4. Complete ANSI C printf formatting with extensions.
  5. Run time linking of libraries and builtins.
  6. A number of additional substring operations such as offset length.
  7. Full extended regular expression matching capabilities
  8. Compound variables which can be used to represent data aggregates.
  9. Name references for passing aggregate variables by name.
  10. Active variables. Users can trap variable assignment and references by associating intercept functions of the form name.get and name.set.
  11. Ability to make socket connections to servers by name.
  12. read with timeouts.
  13. Conformance to POSIX 1003.2.
  14. Command completion and variable completion, ksh93 only had file name completion.
  15. A key binding mechanism that allows users to bind keys to new editing functions.
Note that only the last two features relate to interactive use. The primary focus of ksh93 is scripting and in this arena it certainly outshines bash. ksh93 runs builtin shell commands much faster than bash.

There is actually a third area of shell functionality which is related to extensibility. In this area ksh93 should be compared to tcl. ksh93 is implemented as a reusable library with a C language API for adding builtins and accessing shell internals. It can be embedded in other programs. For example, dtksh, which is part of the Common Desktop Environment (CDE), uses ksh93 as a library. Similarly, tksh, (written by Jeff Korn) which uses the tk library for graphics, uses ksh93 as a library.

The primary drawback to ksh has been that it was proprietary. This has recently changed however. The new AT&T open source license allows ksh source and binaries to be shipped as part of the system and is now just beginning to start showing up in Linux systems; for example the latest slackware. The source or binary for over a dozen architectures can be downloaded from (http://www.research.att.com/sw/download). Hopefully other systems will start shipping ksh93 and start using this for /bin/sh as well.

Question 2) What about enhancing ksh syntax?
by mirko (mirko@myfamilyname.org)

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.

Korn: First of all pdksh is a ksh88 clone; and I might add a better clone than the MKS Korn Shell.

A lot of effort was made to keep ksh88 small. In fact the size you report on Solaris is without stripping the symbol table. The size that I am getting for ksh88i on Solaris is 160K and the size on NetBSD on intel is 135K.

ksh88 was able to compile on machines that only allowed 64K text. There were many compromises to this approach. I gave up on size minimization with ksh93. ksh93 is larger than bash. However, because of the number of commands that can be builtin to ksh93, it is possible to put ksh93 and approximately 30 additional commands on a floppy in approximately the same space as with ksh88 and those commands.

Some of the reasons for the large size of ksh93 are:

  1. Floating point arithmetic.
  2. The use of Sfio for Stdio. Use of the native stdio would not have counted towards the size on most systems because they are part of the shared C library. However, Stdio has too many weaknesses to be used portably and safely by ksh.
  3. Self-documenting code. All the built-ins to ksh93 can generate their own manual page in several formats and locales. This takes up space for the documentation text as well the the processing libraries.
Question 3) pdksh...
by mirko (mirko@myfamilyname.org)

Do you collaborate (or plan to) with the pdksh development team ?

Korn: I don't know the pdksh development team but I would like to thank them for the service they have done in making a version of ksh available while ksh was proprietary. I have noticed remarkable improvements in pdksh in its ability to mimic ksh88 functionality. I don't know what plans the pdksh development team has now that ksh93 is available in open source form, but I certainly would help them try to maintain compatibility if they do continue pdksh distribution. Otherwise, I would hope that they would pick up the ksh93 source and help support and enhance it.

Question 4) ksh today
by Y-Leen

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 machines and the current consumer base, what new features would you include?

Korn: In many ways yes. In early days memory size was a big consideration. [That] sixteen bit machines were the norm influenced the design. The fork() call on most systems caused the data area to be copied in the child process and therefore keeping the data region as small as possible was needed for performance reasons.

Another design principle that was influenced by the hardware and the OS was the desire to only have features that would work on all systems so that korn shell scripts would be portable.

The decision to keep ksh compatible with the Bourne shell was influenced by the consumer base. There are very few Bourne shell scripts that will not run unchanged with ksh.

In a complete redesign, all shell functions would be thread safe so that multiple shell interpreters could run in separate threads.

There are two features that are missing the current ksh93 release that are present in perl and should be added to a future release. One is the ability to handle and process binary data. The second is related to name spaces.

Question 5) True Story?
by travisd (travisd_no_spam@tubas.net)

Was the story about you embarrassing a Microsoftie at a conference true? Specifically, that he was insisting that their implementation 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 someone else finally stood up and informed the speaker who he was arguing with.

Just curious ...

Korn: This story is true. It was at a USENIX Windows NT conference and Microsoft was presenting their future directions for NT. One of their speakers said that they would release a UNIX integration package for NT that would contain the Korn Shell.

I knew that Microsoft had licensed a number of tools from MKS so I came to the microphone to tell the speaker that this was not the "real" Korn Shell and that MKS was not even compatible with ksh88. I had no intention of embarrassing him and thought that he would explain the compromises that Microsoft had to make in choosing MKS Korn Shell. Instead, he insisted that I was wrong and that Microsoft had indeed chosen a "real" Korn Shell. After a couple of exchanges, I shut up and let him dig himself in deeper. Finally someone in the audience stood up and told him what almost everyone in the audience knew, that I had written the 'real' Korn Shell. I think that this is symbolic about the way the company works.

Question 6) Kind of a shell question...
by update()

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? I might have suspected...

Korn: As far as the Korn band is concerned, as you probably already know, it was formed in 1993 to promote the Korn Shell. On the kornshell.com website (click on fun), you can see them endorsing the KornShell Command and Programming Language book, the most complete reference book on ksh93.

There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even perl programmers often miss the point, writing the heart and soul of the application as perl script without making use of the UNIX toolkit.

Our aim with ksh, and with about 150 additional tools that are part of the AST Toolkit, (http://www.research.att.com/sw/download), has been to enhance the UNIX tool kit by providing new and improved tools.

Clearly most users prefer GUI interfaces, and GUI interfaces are often hostile to the UNIX methodology. This presents a challenge for the GUI design and unfortunately many GUI applications are built as monoliths with little hope of reuse and make little reuse of the UNIX tool set. I think that the most important consideration when building a system is to separate the GUI from the rest of the system. Anything that can be done with the GUI should be able to be done without the GUI via scripting. This is important if you ever want to automate tasks in the future. Scripting can then be used for automation and for testing.

This tight coupling between GUI and application has other drawbacks as well. It makes it hard to distribute functionality from the client running the GUI to a server that could be somewhere else on the network.

Question 7) What functionality/code in ksh are you least proud of?
by segmond (segmond[at]hotmail)

It is very hard to find a programmer who is completely satisfied 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?

Korn: The things that I most regret are not the code itself but mistakes that are in the shell language that I inherited from the Bourne shell code. A lot of effort was made to maintain compatibility while trying to improve ksh at the same time. Compatibility was an extremely important consideration for the adoption of ksh by may organizations. At one point I backed out an improvement because it broke one script in a published UNIX book. If I had my choice, the backquote would disappear as a special character and $() would need to be used instead. Double quoted strings would interpret all of the ANSI-C backslash conventions as well as expand $ expansions. The echo command would not perform any interpretation on its argument. Word splitting would be disabled by default. Note that because I did not make these changes, ksh can safely replace /bin/sh on most systems today unlike zsh which would cause many script to fail in mysterious ways.

There are also a number of features that I introduced into the shell that I wish that I had done differently or not at all. Some obvious examples are the poor design of the fc command, the let command which was superceded with ((...)), and the exporting of attributes for shell variables.

The code has changed a lot over the years which I suspect is an indication that I am never completely satisfied with my code. In fact whenever I look at code I wrote a few years ago, I can't believe how bad it is and I always believe that my new code is finally ok.

What bothers me most about the current code, is that, in spite of its modularity, there are too many places where code in one module only works because of the way another module works. The effect of this is that many changes that I make are not orthogonal and require changes to several parts of the code.

Another weakness of the current code is that it is not completely thread safe.

Question 8) UWIN and etc
by rabtech (russ_slash@boneville.net)

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?

Korn: I have spent the last five years writing a UNIX for windows which is called UWIN (http://www.research.att.com/sw/tools/uwin). My experience is with the WIN32 API for the core OS and not with the WIN32 interface to the GUI. Clearly I had to learn more about the WIN32 API than I think that anyone should need to know. The more I know about the WIN32 API the more I dislike it. It is complex and for the most part poorly designed, inconsistent, and poorly documented.

One of the biggest myths about Windows is that the MS operating systems are compatible, unlike UNIX which has so many variants. In reality, porting from one version of Windows to another is often more difficult than porting from one UNIX or Linux system to another. WIN32 calls on one system are not necessarily implemented on other systems, or even worse, they behave differently, requiring completely different code strategies.

That is not to say that there aren't things that I like about Windows NT. The handle model is good, but would have been better if Microsoft had done it right. The separation of dynamic libraries into interface and implementation also makes sense. Putting the libraries in the same directory as the executables is an improvement over UNIX since the allows executables and libraries to be searched for simultaneously.

The best advice I can give is to not use Windows unless you have to, or if you have to, use a UNIX operating system on top of Windows like UWIN or Cygwin.

One insight that I would give about UWIN is that it proved to be far more difficult that I had anticipated.

Question 9) Ksh Programming For the Web
by Dom2 (dom@happygiraffe.net)

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 take up has been slow.


Korn: One of my biggest disappointments is the slowness of adoption of ksh93. At the time ksh88 was released, AT&T was a primary UNIX vendor and was able to put it into the standard product. This led to relatively quick adoption for most vendors.

Shell features like here-documents are very well suited for CGI scripts. However, ksh93 is far better as a web scripting language than ksh88. There is not an efficient way to handle the myriad of substitution operators that get passed into a CGI script with ksh88 or any other shell. ksh93 does this rather efficiently with a 'set' discipline which converts the CGI command line into a single compound variable for manipulation by the script. A 'get' discipline converts it back.

The kornshell.com page has the code for a script that can be included in a CGI script in which all the arguments are mapped into shell variables.

Also, recent version of ksh93 have added %H to printf so that strings can be expanded using HTML/XML %xx; form whenever necessary.

The http://www.research.att.com/sw/download website is maintained by ksh scripts in combination with AT&T nmake, and all CGI scripting is done by ksh93.

Question 10) Graphical dtksh, zend, standardizing on ksh93, rpm
by emil

a) Since the code to Motif is now free and open, is there any possibility that dtksh, the ksh93-compliant CDE shell with Motif extensions will be open-sourced? Novel wrote it; will they give it away?

b) Any possibility that you could leverage Zend from php? Or what would it take to implement a dbi-like SQL layer for ksh?

c) 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 straightened out?

d) Will I ever expect Red Hat to include an RPM for ksh93? Or would you consider merging with Bash?

Korn: a) I can't say whether Novell will give dtksh away or not. They own the ksh93 extensions and its up to them what they do. I don't think that Motif is either free or open since my understanding is that it cannot be included in commercial products. On the other hand, tksh, which combines ksh93 with tk graphics is freely available. In addition to interpreting shell syntax, tksh can interpret tcl syntax as well.

b) I am not familiar with Zend from php. ksh93 is very extensible. Builtins can be added to ksh and use the same calling convention as tcl uses. There is an API interface to shell variables and other shell functions that can be used with built-in commands. If Zend from php can be added to tcl, then it can be added to ksh93.

c) Since ksh88 is not fully POSIX compliant, some system vendors have modified ksh88 to make it compliant and used that for their POSIX shell. One way to clean up this mess is to get all the vendors to move to ksh93. ksh93 has a single source that compiles on all systems from pc,'s mac's, unix systems, and mainframes. I have no say over what vendors do, but users on these systems certainly can state their preferences.

d) I would hope that Red Hat and other Linux and UNIX vendors would pick up ksh93 and distribute it at least as /bin/ksh. There is no reason why it could not be used as /bin/sh as well and I suspect that it could be merged with bash. We will soon be offering RPMs for the entire AST library from the AT&T website.

Question 11) UWIN and Cygwin
by Lumpish Scholar (psrchisholm@yahoo.com)

How would you compare the UWIN and Cygwin projects?

Korn: I believe that UWIN and Cygwin started at about the same time although I don't believe that either knew about the other for the first year or two. The focus for Cygwin seemed to be primarily GNU tools rather than a more complete integration. The primary focus on UWIN was to make the AST tools described in now the out of print book "Practical Reusable UNIX Software", run without change on Windows NT and Windows 95.

Cygwin has the advantage of being an OpenSource project whereas UWIN is not, although hopefully this will change in the not too distant future. However, UWIN binaries have been freely available for educational and research use, and available for 90 day evaluation for commercial use. As a result there are more than 100,000 UWIN users and this has helped in discovering problems. The source for nearly all of the UWIN commands are available in open source.

Cygwin relies on the gcc compilation system. UWIN tries to be compiler neutral and works with gcc and Visual C/C++. Since it works with the Visual C/C++ compiler, it is easier to integrate UWIN code with native Visual C/C++ modules.

The website http://www.research.att.com/sw/tools/uwin/survey.html allows users to compare UWIN with other alternatives such as Cygwin in for different categories. The feedback that I have received shows that in most instances UWIN receives higher marks than Cygwin, especially in performance.

Question 12) ksh93 as a programming language?
by Lumpish Scholar (psrchisholm@yahoo.com)

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?

Korn: In question 1 I gave a quick summary of ksh93 features that distinguish it from ksh88 and from other shells. For the most part ksh93 has the functionality of perl 5 and arguably a more readable syntax. In most instances the performance is similar. Scripts that interact heavily with the file system or use pipelines tend to be better suited for shell scripting.

Question 13) So, Dave ...
by An Unnamed Correspondent

Quick question: Vi or Emacs?

Korn: This is an old battle that was raging in the early '80s. It will never be settled. This is why ksh has both edit modes. It partly depends on whether you use the editor as a command or as an environment. I think of an editor as a command that I can quickly start and leave and I think of the shell as an environment which holds state. vi fits this model better and that is what I use.

I use several versions of vi depending on which system I am on. UWIN uses nvi from BSD.

Question 14) Public Apology
by watanabe (petervNOMEATivcfne.org)

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

Korn: Since I could not recall the incident, I asked by son Adam to respond to this. Here is his response:


Thanks for clearing things up! In my memory of the incident, we had woken you up that evening and I thought you said to me, "I hate the Korn smell." I was mortified! That was the first time anyone ever (publicly) accused me of having b.o., and your comment gave me quite a complex for the many months that followed. I avoided you at all social gatherings because I was scared to death that you might mention this in front of others. I am relieved to learn that this was all the result of a simple miscommunication.

To be honest, I have no recollection of this incident. I do appreciate your apology, but it is not necessary -- just as people are entitled to their choice of music, art, religion, etc, they too should have the right to pick their favorite shell. I'm just thankful I'm not the son of Bill Gates!


Our thanks to David for his responses, and likewise to Adam for his.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Re:"vi is better than emacs" (1)

Anonymous Coward | more than 13 years ago | (#449375)

Yeah, but he said something about Emacs maintaining state.

Heck, I thought Emacs was a state.

Oh my god (1)

Anonymous Coward | more than 13 years ago | (#449376)

I can see it now. The next generation of sysadmins will all use ksh instead of bash because they all are KoRN fans.

Oh, the humanity !!!

Re:Experiences with UWIN (1)

Anonymous Coward | more than 13 years ago | (#449377)

My experience has mainly been with the Uwin team at AT&T, and to a lesser extent with the Global Technologies people. But both have been very helpful, and quick to fix bugs. I've mainly been using Uwin to provide a Unix working environment (especially shell scripting), to drive the Microsoft development tools. So I can see how our experiences differ. Programming at the level of shared memory stuff (which tends to cause problems just between different versions of *Unix*), is expecting something close to a miracle from Uwin. To me (having read the early white paper on getting a Unix environment under Windows), Uwin seems to do an almost miraculously good job, considering the difficult starting point. Being on the Uwin mailing list for years has been highly educational too. From that, it seems pretty clear to me that the bulk of the work in Uwin is achieving a complete mixture of workarounds to different sets of problems and bugs in the many different flavours of Windows, and presenting a uniform interface that hides all the ugly workarounds. The kind of thing I'm thinking of is the fact that the Microsoft implementation of popen() under Windows 95 OSr1 caused a floppy disc access! So using pipes in programs I'd written, you'd hear lots of grunting from the floppy drive. Uwin's pipes did not suffer from the same problem. They'd obviously worked around it. Luke Kendall

Re:*shudder*... (1)

Geoff (968) | more than 13 years ago | (#449379)

I had a similar thought. Bash the standard UNIX shell?????

And thanks for the link about ed. That was hilarious.


Re:This was empirically proven... (4)

ptomblin (1378) | more than 13 years ago | (#449381)

The vi team won because the Emacs team wasn't used to only pushing one button/trigger at a time to issue a command/paintball. If there had been a Control-Alt-Meta-Cokebottle-trigger mode, then the emacs team would have won handily.

Re:This was empirically proven... (2)

jafac (1449) | more than 13 years ago | (#449383)

Yeah. That's why I chose vi as my "editor of choice". Those whimpe emacs guys. I just couldn't stand the thought of using the shell represented by a bunch of loser pantywaists.

Anyway, "vi" is the heart of "evil".

Re:Executable sizes (2)

mangino (1588) | more than 13 years ago | (#449384)

It is extremely important to compile your /bin shells staticly. That way you can recover in case you screw up /lib or ld.so
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Re:Korn Shell question (2)

slim (1652) | more than 13 years ago | (#449386)

If true, that's an interesting little problem,

It is true. To my delight, David Korn sent me a mail explaining it. In a nutshell, it's deliberate. The original Bourne shell interprets " a | b " as "(a) | (b)". Bash and pdksh do the same. Korn thought this was counter-intuitive (he's right), so ksh reads it as " (a) | b ". It works for all shell builtins, not just "read".


Korn Shell question (4)

slim (1652) | more than 13 years ago | (#449388)

Shame I missed the call for questions: I'm interested in a quirk of ksh and its clones:

Consider this code:

echo "goodbye" | read x
echo $x

In both bash and pdksh, running the script would return "hello", because the "read x" would be run in a subshell with its own environment. The subshell would then close without affecting the instance of x in the main shell.

In ksh, however, putting 'read' at the end of a pipeline does not seem to run it in a subshell, so running the script would return "goodbye" just as the naive reader of the code might expect.

Why is this? Is an exception made for the "read" builtin? Is this a deliberate feature that pdksh and bash have failed to clone, or is it happenstance that it came about? I assume David is too busy to be reading, so does anyone else know?

In our ksh-happy shop, we have a lot of scripts that rely on "echo $string | read x y junk" to parse space-seperated lists, and of course these statements don't port well to Bash (you have to do a few backtick/sed operations).

Re:Korn Shell question (1)

Wheely (2500) | more than 13 years ago | (#449389)

If true, that's an interesting little problem, i'll have to try that when I get to the office. On a par with how does "find . -name * -print" work these days when it you used to have to escape the *. Also "tar xv *" works in some shells these days too.

Must be progress.


This was empirically proven... (2)

slothbait (2922) | more than 13 years ago | (#449393)

a few years ago at (I believe it was) Linuxworld. In an effort to finally settle the age old debate, there was a paintball battle between Team Emacs and Team vi. O'Reilly supplied team shirts, with the respective book covers on the front. There was a fair amount of trash talk on Slashdot before the event. Mind you, these were the early days of Slashdot, and most readers had actually used both.

The match went to Team vi. It is worth noting that they fielded a larger team. To this day, I feel guilty about not attending that conference -- it's quite obvious that Team Emacs needed me.

Ah...the earl(ier) days of Linux.


Nostalgia (1)

Shimmer (3036) | more than 13 years ago | (#449394)

I was weaned on Unix systems many years ago and have been assimilated into the Windows world since. Reading this definitely makes me nostalgic for the well-defined old days. One good thing I can say for Windows, however, is that it is finally taking Korn's advice to allow via scripting (e.g. the Windows Scripting Host) most things that can be accomplished via the GUI.

-- Brian

Re:GUI environment shell (1)

peter (3389) | more than 13 years ago | (#449395)

Well, I know of one seriously GUI programming language. National Instruments' LabVIEW. (If you install the trial version on a windoze computer, be careful, because it doesn't uninstall very well, IIRC. I don't know if the linux or solaris ports have trial versions available.) see www.ni.com

I'm not a big fan of LabVIEW, being more of a text-and-command-line C programming kind of hacker. A couple of my friends are making huge dollars writing labview code for instrumentation and control stuff. One of them told me he likes labv so much because he's a visual person. He's a lot more right-brained than me; He's actually left handed. Labv is great for him.

However, don't let marketing fool you. Labv is just another programming language. You design the data flow, rather than a set of instructions, but it is not fundamentally different from anything else. It's just a lang with a big library of many high-level functions. (If it wasn't for the library, it would be a nightmare to write anything...)

Labview has big weaknesses. If you want stuff to happen in a specific order, you have to do a lot of extra work. If you want to read with timeouts and/or handle errors, things get a lot harder.
#define X(x,y) x##y

Re:"vi is better than emacs" - nope yea. but. . . (1)

heller (4484) | more than 13 years ago | (#449396)

. . that's only cuz once it's loaded there's no resources left for any other editor! ;->

** Martin

Re:Executable sizes - uh. re-read that. (1)

heller (4484) | more than 13 years ago | (#449397)

Dude. those are sun sparc versions. says so right in the top line. The size on linux systems are a completely different story.


** Martin

Re:So which OSen have ksh93 installed by default? (1)

Bigbambo (8887) | more than 13 years ago | (#449398)

freebsd has ksh93 in /usr/ports/shells/ksh93

all ya gotta do is cd there and type make install clean

Re:Korn Shell question (1)

Macka (9388) | more than 13 years ago | (#449399)

I would have said that the ksh behaviour is the correct one. "read" is a ksh builtin and should not execute in a subshell unless surrounded by either $() or `` and in either case I would expect very strange results from that.

Hmm ... I'm looking at this using ksh on a Tru64 Unix box right now .. I'll experiment more on my Linux box when I get home later.


bash is broken (1)

Macka (9388) | more than 13 years ago | (#449400)

I see what you mean. I disagree that bash is executing "read" in a subshell, as "read" is also a bash builtin function. However I think that bash is broken here.


Re:Executable sizes (2)

arivanov (12034) | more than 13 years ago | (#449403)

That is called: some stupid moron compiled libreadline statically. Not amazing...

I would outright disagree with most statements (2)

arivanov (12034) | more than 13 years ago | (#449404)

Ksh syntax more readable than perl... Yeah right. I have read enough IBM install scripts or semi-insane scripts from commercial solaris software to object. Well written ksh is more readable than horrible perl, but it does not even get closed to proper perl.

Perl developers not using unix system toolkits. Well... there is a reason for it. Specifically related to temporary files, the system call versus fork/exec and so on. Most ksh programs I have seen (including parts of commercial software) do not take these subtleties into account. As a result they are full with root holes. Perl programmers have learned to take them into account the hard way

Ksh faster than perl. Seeing is believing. Unless we are talking about arithmetics where perl traditionally does not cut the mustard...

Ksh more extensible than perl... Well... Once again seing is believing... So far just looking at CPAN the answer is "bulshit"

All you need to know about csh programming (1)

rcp (12077) | more than 13 years ago | (#449405)

chsh won't work? Sysadmin won't edit /etc/shells? Don't have permissions on /etc/passwd?Why not explore the wonderful world of csh programming on Solaris? Start with the following one easy step!

  1. Add the following to the end of your $HOME/.cshrc:

    if ( -x /usr/local/bin/ksh ) exec /usr/local/bin/ksh
    if ( -x /usr/local/bin/bash ) exec /usr/local/bin/bash

Re:Default shells (2)

rcp (12077) | more than 13 years ago | (#449406)

Disclaimer: I hope this doesn't become a shell war thread... :-?

Damn your eyes for that suggestion! You make outrageous inflamatory statements like "csh is OK" and expect to be left off the hook? I call on all followers of the One True Shell (whichever one it is for you) to declare war!

Re:*shudder*... (1)

Lx (12170) | more than 13 years ago | (#449407)

Yeah, that jumped out at me. Some people have difficulty with the concept there are other UNIces than Linux(for which bash seems to be really common - after all, it's GNU).


CGI's using a shell (2)

MSG (12810) | more than 13 years ago | (#449408)

The kornshell.com page has the code for a script that can be included in a CGI script in which all the arguments are mapped into shell variables.

Now that just strikes me as a terrible idea. Bad things happening to shell variables is exactly why you should not write CGI's using a shell.

Really. If you don't yet believe the awesome power of unchecked variables, then read Perl's security docs [perl.com] and learn about Taint mode. Check the FAQ's to see a small example of how often poorly checked input in CGI leads to a compromise. Taint mode specifically is what makes Perl my prefered language for CGI (among my primary languages: C, Perl, Python)

Re:Old ideas (1)

joshv (13017) | more than 13 years ago | (#449409)

You sir do not understand the UNIX Philisophy. You have no business using UNIX to say such things.

Enlighten me. Explain to me what the Unix philosophy is. I myself was merely paraphrasing the philosophy Korn expressed in his answers to the slashdot questions.

Better solutions?! I would argue that GUI and console are apples and oranges.

I am not talking GUI versus console apps. You can write both GUI and console apps in Java. Java has a much better solution to code reuse than the one Korn appears to love. So does Python, or even Perl for that matter.

I would also agree with Korn that the GUI and shell belong separated at all costs.

I would argue that if people would make good GUI tools, I would not need a command shell. And actually, for the most part I almost never use one. Though I used to find them very convenient I simply do not have the time or the spare brain cells to waste on remembering the arcana of a 'find' command when I can alias control-F to pop up a nice GUI dialog that has tons of options and will nicely sort the results

Does this mean I am decades behind the times? That sounds like something Microsoft would say.

Sure does sound like something microsoft would say. But I didn't say it.

But I am a younger programmer. I don't know how 'old fart' Mr. Korn is, but it's safe to say that I am at least a few decades younger. Would this be backward evolution by your standards?

Not sure what I'd call it. Certainly not backward evolution. But you will eventually find yourself unable to compete with those who take advantage of newer technologies


Old ideas (3)

joshv (13017) | more than 13 years ago | (#449410)

I understand what he is talking about in terms of building new tools based on resuable 'toolkits' of shell commands, but I think Korn's ideas on code resuability are incredibility out of date.

The tools he talks about operate on text streams which are piped from tool to tool. There is no structure to the text streams and it is up to every tool to figure out what the stream contains on it's own. Is it HTML? A Text file? /etc/passwd? To top it off, each tools has it's own arcane syntax and combinations of command line switches - a support, training and maintenance nightmare.

This just does not strike me as a particularly good way of doing things. It was an excellent solution to the problem of resuability back in the days when hardware was slow and memory was limited. But today we have better solutions, and the only reason I could see to use these older tools is for the sake of backward compatibility.

The idea of building a web site using shell scripts strikes me as patently absurd. Sure it can be done, but why, when there are much better tools for the job - and all of these tools have solved many of the code reuse problems of the past in a much more elegant fashion than the Unix 'toolkit' has.

His comments on modern GUIs show a certain naivité about the state of the art of GUI design. Both KDE and Gnome have an extensive object models, and their own component and application toolkits which support code reuse and the building of your own personal 'toolkits'. His critique of GUIs might more appropriately be levelled at older Motif applications, where every app truly is an island unto itself.

It just seems that Korn is living a few decades behind the times. He deserves respect, but his ideas are anachronistic at best.


I'm surprised that nobody has brought up (1)

nosferatu-man (13652) | more than 13 years ago | (#449411)

... what is by far the coolest thing in the whole interview:

All the built-ins to ksh93 can generate their own manual page in several formats and locales.

That's almost enough to get me to start using it. Thank you, David Korn. It'd be a pleasure if other authors took this idea and ran with it, especially on systems with the more brain-damaged documentation (you know who you are.)


Re:Korn Shell question (1)

MO! (13886) | more than 13 years ago | (#449412)

Not that I can answer your question, but I'd like to help narrow down it down a bit. I'd also, merely for curiousity reasons, like to know the answer.

So, that being said: Are you using ksh93 or an older ksh88-based shell?

Just from reading the above responses, it appears ksh93 has a much richer scripting environment. You mention that pdksh, which is based on ksh88, processes the statement as bash does. I would assume from this that you're using ksh93, and the difference is most likely due to the extended scripting functionality. That functionality would not be present in pdksh or bash, since they are not based on ksh93.

Re:Korn Shell question (2)

Greg W. (15623) | more than 13 years ago | (#449415)

In our ksh-happy shop, we have a lot of scripts that rely on "echo $string | read x y junk" to parse space-seperated lists, and of course these statements don't port well to Bash (you have to do a few backtick/sed operations).

Actually, you can still do it with shell builtins. Save off the current argument list ($*) if necessary, and then:

set -- $string
x=$1; shift
y=$1; shift

I have to agree, though, that the ksh implementation is better.

So which OSen have ksh93 installed by default? (2)

bee (15753) | more than 13 years ago | (#449416)

Does anyone know which OSen (or Linux dists) have ksh93 installed with them? Even if it's installed as (/usr)/bin/ksh93 it'd still be nice to see it get out there and get used, since it sounds like it has some really cool features.


Re:*shudder*... (1)

sharkey (16670) | more than 13 years ago | (#449417)

An asumption like this should earn him /bin/ed as a standard shell... :)

While quite to the point, I would advance this shell as more fitting: c:\windows\progman.exe.


Fix the damn BOLD tag! (1)

Pope (17780) | more than 13 years ago | (#449419)

Someone forgot to close the BOLD Tag!


Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!

Re:So which OSen have ksh93 installed by default? (1)

Saint Nobody (21391) | more than 13 years ago | (#449421)

that particular tasteless joke is in fortunes2-o.

this begs the question, Why the hell are they including offensive fortunes in the bottom of the page? and yes, "offensive" is the official designation, and they are separate from regular fortunes, requiring an additional parameter on the fortune command.

(besides, there's much better offensive fortunes than that. just rot13 it and search for the word Radcliffe in a Jabberwocky parody.)

The place to get ksh93? (1)

bliss (21836) | more than 13 years ago | (#449422)

Well I guess I must be the first to actually post something serious about the korn shell. Having been forced to program in pdksh because of a lack of actually having access to ksh93 in debian I wonder where one can actually get it?

Equality (2)

SuperKendall (25149) | more than 13 years ago | (#449423)

I hate to dilute a humorous comment with dry commentary, but I thought the answer he gave there was one of the most even-handed and fair responses I've ever seen to that question.

I personally use Emacs most of the time as I like the environment it provides for generating code. However, I also have a good working knowledge of VI because there are a number of times when I want to use an editor as a tool to get a job done quickly.

That said, I have to mention that if you set up Gnuclient for Emacs, you get to have your cake and eat it too - you can start and dispatch an Emacs editing session just as quickly as VI by attching to an already running Emacs. So for machines that you've customized, Emacs makes for as good a tool as an environment.

Double Public Apology (5)

watanabe (27967) | more than 13 years ago | (#449424)

Dr. Korn,

I'm chagrined to see that you and your son are more gracious and funnier than I am. All the best; I think it's clear I need to learn to use your shell.

- Peter Vessenes

KSH / other ATT tools not Free? (2)

Hobart (32767) | more than 13 years ago | (#449425)

http://www.research.att.com/~gsf/download/faq.lice nse.html [att.com]
  • Is the software OpenSource?
    We believe that it conforms to the provisions of the Open Source Definitions (OSD), and have submitted the license for certification, but we have not heard back.
... perhaps since OSI isn't contacting them, they can choose a ready-made Free Software License [fsf.org] -- there's 15 to choose from that will maximize the real ksh's availabilty, adoption, etc...

Re:GUI environment shell (4)

hey! (33014) | more than 13 years ago | (#449426)

I think the issue is that programming is largely a verbal, logical thing rather than visual. I've yet to see a visual programming environment that really doesn't boil down to a "so what" at the end of the day. IBMs visual age stuff is fairly nice, but mainly because it gets out of the way in a hurry when you really need to get down to brass tacks.

I think the shell as programming environment is a kind of curious historical accident that worked out really well in conjuction with a broad variety of filter-ish applications. If you think about it, there is little reason why your shell should be your primary glue language for all kinds of applications, other than you happen to be spending a lot of time typing in it if you are on a non-gui system.

If you relieve the application of having to be your primary mode of interaction with the file system and for launching applications, you can look at various applications as repositories of objects to be used rather than processes to be evoked. Yes, I know you can do more with shell scripting, but this is the sort of task shell scripting is natural for -- to evoke a series of small tools that perform simple kinds of transformations on a file system or data stream. These are highly useful, but aren't the entire universe of scripting applications.

It's been a few years, but the nicest example of of system scripting I've ever seen is Applescript. In MacOS, applications tell the system about objects and methods that they are willing to expose. They are essentially self documenting. These objects can be manipulated through low level APIs, but they can also be accessed by Applescript via a form of message passing. Applescript was a very small, simple and relatively clean scripting language. It had various sugary constructs that allowed you to make script lines sound like reading English sentences, but they were tastefully done and they weren't obtrusive if you liked things terse. Apple provided a small interactive editor/interpreter environment (vaguely a la WISH or IDLE but less funky) which could inspect the self documenting features of the applications' objects. Scripts could then be saved and run like Unix shell scripts.

Applescript was sort of like a cleanly done VBA, but it's real strength was that it was a tidy way to coordinate a number of processes whose lifespan were not related in any preconceived way to the lifespan of the script and do itneract with them in a very flexible way. In that sense it was kind of like workign with application COM services. Integration with the Finder gave you the kind of shell script capabilities you'd expect in Unix.

I've been out of the Mac world now for six or seven years, but they were definitely way ahead of their time. Applescript was a relly valuable technology that was hurt by Apple's failure to deliver OpenDoc and at one point Apple was even going to abandon it.

Re:Fix the damn BOLD tag! (2)

segmond (34052) | more than 13 years ago | (#449427)

you are just as wrong as them, it is the strong tag. :p

they have a ...
how sad that our fearsome ahem ...leaders can't verfiy html code before throwing it on the front page.

Re:Finally a voice of sanity (1)

MadAhab (40080) | more than 13 years ago | (#449428)

It probably has less to do with screen re-drawing and more with memory usage; on a loaded server, vi would feel smaller for this reason. Even vim is much smaller than emacs.

Another pro-vi observation is that it's on virtually every machine out there - out of the box. That's a big plus.

Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.

Re:How can I tell what version I have? (1)

kps (43692) | more than 13 years ago | (#449429)

In vi editing mode, type ESC Ctrl-V

In emacs editing mode, type Ctrl-V

Re:UNIX commands in Perl (2)

drivers (45076) | more than 13 years ago | (#449430)

I would say that perl would be good for writing customized little utilities that can then be tied together in shell scripts.

You know, any little program that goes:

(simple filter-type perl program deleted, because SLASHDOT LAMENESS FILTER SUCKS! Oh well.)

and does funny stuff with the input and sends it to the output. (If you are looking at things from a unix point of view.)

Re:"vi is better than emacs" (1)

Pedersen (46721) | more than 13 years ago | (#449431)

Nah, what was meant was that whole state populatoins are required to maintain emacs.

Re:Equality (1)

jcn (55250) | more than 13 years ago | (#449432)

Hmm, that sounds handy, I'll try it right away. Hint:
18:52:38 appel ~$ gnuclient
bash: gnuclient: command not found
18:52:40 appel ~$ apt-cache search gnuclient
18:52:46 appel ~$ emacsclient foe
Waiting for Emacs...^C
18:52:50 appel ~$ zgrep gnuclient /root/Contents-powerpc.gz usr/bin/gnuclient editors/gnuserv
18:52:58 appel ~$ su -c 'apt-get install gnuserv'
This looks fine: why didn't you tell me before? It seems that I won't need vi for quick stuff anymore! Too bad that (server-start) and (gnuserv-start) bite eachother, we'll probably have to patch gnuclient also to enjoy our 31337 Point 'n Click [lilypond.org].

Re:KSH / other ATT tools not Free? (1)

RonVNX (55322) | more than 13 years ago | (#449433)

I was at David Korn's talk at NYLUG.org and I believe he said there were a few issues, related to AT&T's lawyers. As I recall, RMS has a problem with the requirement to check the site periodically to make sure the code you previously downloaded hasn't come under patent attack by a third party.

Re:I'm very stupid, please explain (1)

PurpleBob (63566) | more than 13 years ago | (#449434)

No, no, it's "'i' before 'e' except when it's not."

Works every time.
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.

Re:Finally a voice of sanity (1)

Ded Bob (67043) | more than 13 years ago | (#449435)

Even though I am mostly a vi person, I sometimes use Emacs--don't let people know. :)

Actually, I prefer a clone which might suit you as well: Zile [sourceforge.net] It is quite small and quick compared to Emacs.

Ksh the Shell vs. Ksh the Script (2)

Ted V (67691) | more than 13 years ago | (#449436)

Basically what David Korn says is that all the good shells (or at least popular shells) are similar in terms of interactivity: bash, tcsh, zsh, ksh, and a handfull of others. His selling point is that Ksh has far superior scripting capabilities than the other shells.

As a shell, I personally prefer zsh because the interactivity is a little more customizable than ksh. As a scripting language, I personally prefer Perl because the scripting is more syntactically flexible. (That's a nice way of saying that Perl lets you write both readable code and slash code.)

I won't claim that ksh scripts are inherently messier than a dedicated scripting language. Perhaps I've only seen bad examples of ksh scripts, and I've seen my share of bad perl scripts as well. I will claim, however, that there are other scripting languages which are more expressive than ksh and other shells which are more interactive than ksh.

So I think it's great that ksh scores a 9 out of 10 on interactivity and an 8 out of 10 on scripting, but I can't help but think that Ksh has bridesmaid syndrome-- always second to something else. Sure, you can use your shell to script. You can use your emacs text editor to read news, mail, and play games if you want to. Personally I'd rather have more functionality in each specific area, be it interactivity or scripting.


Perl is absolutely faster than Ksh: Proof (2)

Ted V (67691) | more than 13 years ago | (#449437)

At Motorola, I worked on a project where we wrote a simulator in Perl to interact with a complicated piece of Cell Phone hardware. The hardware ran compiled C code. We once found a bug where the perl simulator sent network packets so fast that the C code crashed from overflow! We actually had to cripple the (perl) simulation to send code downloads slower so the system wouldn't crash.

Incidently, badly written ksh looks a lot like badly written perl. I've never seen well written ksh, but I know Perl is a far more expressive language, so logically Perl code has more potential to be readable.


Experiences with UWIN (2)

Ted V (67691) | more than 13 years ago | (#449438)

I once had the displeasure of working with UWIN in a corporate setting. I had just been transfered to a group that produced a tool consisting of 4 posix-compliant C programs multithreaded together using Ksh scripts to glue pieces. No disrespected intended to Ksh itself, the whole code was an utter an complete pile. (As for functionality, the optimal solution involved 1 perl script, no C code or ksh, and it would have taken me a few weeks to do it.) The code took some 2 or 3 years to write, presumably because they used all sorts of great but unnecessary posix features like shared memory maps. Apparently the code really did run fine on a system like Solaris.

Anyway, everyone who worked on the project left the group in 6 months, but the PHB hadn't figured this out. The product was 2 years overdue for their Solaris to Windows port. The engineers decided to use UWIN rather than rewrite in Windows because they thought it would be less effort. Those engineers had since left. What we discovered working with with the Global Technologies company supporting UWIN was that UWIN didn't properly support most of the strange features our code used. Roughly 95% of the problems were due to Posix incompatabilities in UWIN. I would routinely spend 2 weeks talking with Global Technologies pointing out that the bug really was their fault and why the solution was NOT for us to change our code to match their bug behavior. After they hacked together their changes, they didn't even bother testing if the change left their code Posix compliant, expecting us to test. After that, they'd say that it must be our fault it doesn't work and the cycle would complete, until I could show where else they messed up.

A few months later I left for a group working on useful things.

Anyway, UWIN is a great idea, but the people developing it are completely incompetant. (A few times it turned out that I knew more about posix features than they did, and I'm just a standard software engineer.)


Sig (Off Topic) (2)

Ted V (67691) | more than 13 years ago | (#449439)

I made the sig before Slashdot had a shorter max sig length and never bothered changing it. The official quote is:

"Like the situation at ski resorts of young women looking for husbands and husbands looking for young women, the situation is not as symmetric as it appears."


Executable sizes (1)

TommyW (75753) | more than 13 years ago | (#449440)

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

On a Linux system, these are approximately 300k for bash and 160k for (pd)ksh.

That's *not* 300k. That's 3 meg ;)
Too stupid to live.

It's one of the best features of ksh vs. /bin/sh (2)

billstewart (78916) | more than 13 years ago | (#449441)

I used Korn Shell extensively for programming back in the 80s and early 90s, and that was one of the nicest features - it made it possible to implement things clearly and cleanly that were otherwise very annoying. Parsing various argument lists is a common task, and this is good for it. Most of that was ksh88, but some was earlier ksh versions.

Re:*shudder*... (1)

orangesquid (79734) | more than 13 years ago | (#449443)

Ohmygod! Are you *serious*?
I just have these Linux computers here, and my Linuxirix SGI and Linuxnetbsd PC on the desk behind me!

Isn't it funny how Linux's buzzword popularity has pushed other UNIX vendors to offer Linux support on their systems?

Re:Screw them both (1)

mcrandello (90837) | more than 13 years ago | (#449444)

Try nano sometime. I remember hearing about it first a year or two ago, I believe it was an attempt to rewrite Pico under the GPL...although there are a few nice things in it like a search/replace function, plus it's not tied to pine (which my OpenBSD won't install from ports w/o editing the makefile, something about being unsafe or some kind of bother).

Re:Finally a voice of sanity (1)

Rohan Talip (91270) | more than 13 years ago | (#449445)

It would depend on whether Emacs was brought up in X-window mode or no window mode. It is possible to get Emacs binary distributions both with and without X-windows support.

If the version of Emacs that you are using has X-window support, then it is possible to turn this off (emacs -nw); this can greatly speed up editing over a slow link as the X packets (e.g. redraws, mouse movements etc) don't have to be sent, just the changes in the text screen. Rohan

tcsh for interactive shell (3)

Rohan Talip (91270) | more than 13 years ago | (#449446)

I can't claim to have used ksh much, but that is because I have found tcsh to be the best interactive shell (so far) and generally just use the plain original Bourne shell (sh) or awk or Perl for scripting.

However here are some of the features I like in tcsh:

  • set prompt = "%B%c2%b `whoami`@%m%$shlvl "
    #Custom prompt with the name of the current directory, user and server: very useful for sys admins of many servers with many roles

  • set who = "%B%n%b has %a %l from %M at %t on %w %D."
    set watch = (0 any any)
    #Watch who is loggin on or off the system and from where

  • set autologout = (120 60)
    #So you don't accidentally leave terminals/connections open

  • set complete = enhance
    #Case insensitive completions, ".-_" as word separators, "-" and "_" considered equivalent

  • set autolist
    #List possibilities on an ambiguous

  • set pushdtohome
    #Make pushd with no args do a "pushd ~" (like cd does)

  • set cdpath=(. .. ../.. ~ftp/pub/downloads/{ftp,http} /somedir) #Iust type "cd www.kernel.org" from anywhere and voila, "pwd" shows /home/ftp/pub/downloads/http/www.kernel.org

  • set listjobs
    #List all jobs when suspending completion

  • set printexitvalue
    #Print non-zero exit values upon program completion

  • set ignoreeof
    #Don't kill shell when ^D seen

  • set noclobber
    #Don't overwrite an existing file when using ">"

  • set rmstar
    #Prompt the user before execution of "rm *" !! :-)

  • alias cd "cd -v"
    alias precmd /bin/echo ""
    alias + "pushd -v"
    alias - "popd -v"
    alias = "dirs -v"
    #Some useful aliases to show the directory stack when moving around, and to insert a blank line before prompts

  • complete cd 'p/1/d/'
    complete rmdir 'p/1/d/'
    complete set 'p/1/s/'
    complete setenv 'p/1/e/'
    complete unset 'p/1/s/'
    complete unsetenv 'p/1/e/'
    #Completions on aliases, shell variables, environment variables, directories, etc.

  • History searching and substitution

  • Redirection of stderr (cmd |& tee output), although I sometimes prefer the Bourne way of being able to select stderr independently
I hope someone finds this useful, because I love tcsh and even though I am quite capable when using sh, bash or ksh, I usually feel so hamstrung that I install tcsh PDQ if it hasn't been already!

Re:Finally a voice of sanity (the true answer) (1)

Christopher Biggs (98469) | more than 13 years ago | (#449447)

The true answer to "vi or emacs" is: BOTH.

I start up emacs once a week on monday morning. It runs all week, firing up new windows as required.

I run vi hundreds of times a day, for all the little things.

Emacs is good at some things, vi for others. Use a tool for what it's good at---isn't that a direct corollary of the Unix Philosophy?

Re:Korn Shell question (1)

vinyl1 (121744) | more than 13 years ago | (#449449)

I cut and pasted your code, and got 'hello'. I'm on Solaris 2.6. It's not clear what ksh we have, but I'm pretty sure it's not ksh93.

So maybe this trick isn't so safe? Perhaps someday you'll upgrade something and your scripts will stop working.

Re:Default shells (1)

CptnHarlock (136449) | more than 13 years ago | (#449450)

I've used and installed/managed SunOS, Solaris, OpenBSD, Linux and used (not managed) QNX, FreeBSD and NetBSD. Only on Linux I've seen bash as a standard shell. csh is OK but there is tcsh which is as good as bash IMO. Yes it does have filename completion and history. I use both.. :)

Disclaimer: I hope this doesn't become a shell war thread... :-?

"No se rinde el gallo rojo, sólo cuando ya está muerto."

*shudder*... (4)

CptnHarlock (136449) | more than 13 years ago | (#449451)

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)...
An asumption like this should earn him /bin/ed [hmc.edu] as a standard shell... :)

"No se rinde el gallo rojo, sólo cuando ya está muerto."

GUI environment shell (2)

mikeee (137160) | more than 13 years ago | (#449452)

Hmmm... I'd like to see a shell that provides a command-line, programmatic interface to some of the Linux desktop librarys (GNOME, KDE) in much the same way that ksh and its ilk provide the same to the basic POSIX APIs of a baseline UNIX system.

Eg, you could write a script to go searching through a gnome-vfs 'filesystem' or such...

Or am I on crack?

Re:I'm very stupid, please explain (1)

carlos_benj (140796) | more than 13 years ago | (#449454)

Remember: "i" before "e" except after "c" except for the word "weird."

No, it's, "'i' before 'e' except after 'c' or when pronounced 'a' as in neighbor and weigh... oh, yeah, and that weird weigh too." But some people just aren't wierd... er, wired for spelling.

Re:*shudder*... (1)

Lozzer (141543) | more than 13 years ago | (#449455)

For the first time ever that I use these three letters, its actually literaly true...


Thank you

Re:So which OSen have ksh93 installed by default? (1)

ILikeRed (141848) | more than 13 years ago | (#449456)

Read the article again:

is now just beginning to start showing up in Linux systems; for example the latest slackware. The source or binary for over a dozen architectures can be downloaded from (http://www.research.att.com/sw/download).

Install it yourself....

And what is up with this quote (from the bottom of slashdot - where do you guys get these????)

Q: What do you say to a Puerto Rican in a three-piece suit? A: Will the defendant please rise?

Re:I would outright disagree with most statements (1)

drinkypoo (153816) | more than 13 years ago | (#449458)

Perl developers not using unix system toolkits. Well... there is a reason for it. Specifically related to temporary files, the system call versus fork/exec and so on. Most ksh programs I have seen (including parts of commercial software) do not take these subtleties into account. As a result they are full with root holes. Perl programmers have learned to take them into account the hard way

There is, of course, more to it than that. The security is actually your least worry, IMO. You can screen arguments passed to programs. For instance, you can defeat buffer overflows being passed through your script by simply checking argument lengths. Of course, that involves some additional overhead.

No, the reason that perl programmers (or scripters or whatever you want to call them) tend to avoid calling external programs, or call them through modules, is twofold. First of all, those programs, while fairly small, still may do much more than you want to do. If I want to print a file to the screen, I don't use cat; It has code for handling pipes and whatnot. I open() the file, and while I print;. Then I close it. This way, I don't have to deal with invoking all the excess nonsense, starting up an external program, and so on. Just because there's an external program there doesn't mean I want to deal with it.

The other issue, of course, is that I don't care to deal with interpreting the output of another command. Mr. Korn, it seems (though I know this isn't true) would have us calling external programs to get an IP address instead of calling gethostbyname(). I'm sure there's a better example than that, but hey, I'm in a rush. The point is, it's easier to reinvent the wheel sometimes, and your code executes faster, especially in low memory (or slow I/O) situations.

Ksh faster than perl. Seeing is believing. Unless we are talking about arithmetics where perl traditionally does not cut the mustard...

What I want to know is, "Faster how?" Startup? Total execution? File handling? Mathematics?

Ksh more extensible than perl... Well... Once again seing is believing... So far just looking at CPAN the answer is "bulshit"

I don't think ksh is more extensible than perl, either, but not because there are more extensions currently available, but because I don't think one is more extensible than the other. How could you say, for example, "Java is more extensible than C++"? They're both languages, you can write your own code for both, and both can tie into external programs. Hence, neither one is really more extensible than the other, and it's simply a matter of what people are willing to bring to the language.

This is the same way. Personally, I don't see ksh (ksh93 or otherwise) ever being as popular as perl. Perl is just so easy, there are so many books on it, there are so many modules, et cetera. I haven't touched ksh93 (nor do I intend to, more on that later) but I can't see it being easier to write than perl. Also, shell script, when it reaches a certain level of complexity, tends to look like ass. I don't know about ksh93, but since so many things were done for bourne shell compatibility, I suspect it's the same.


Re:Korn Shell question (1)

VoidOfReality (156286) | more than 13 years ago | (#449459)

Just my $0.02 on how wildcard substitution works in shells...

In my experience, if you're in a non-empty directory and type "echo *" (no quotes), the output will be a space-separated list of all the files in the current directory (no dotfiles though). However, if you try that in an empty directory (or, more accurately, in a directory that only has dotfiles in it), remarkably enough, the output is a single asterisk.

It seems that the shell will try to substitute files for the * wherever it can, but if it can't, it will pass the * straight through to the command underneath. This also works with other wildcards like the ? or the [] wildcards. FWIW, all these experiments were run under ksh.


Re:I'm very stupid, please explain (2)

MsGeek (162936) | more than 13 years ago | (#449460)

Yes, but nobody asked him about Brother Korn, Japanese rapper and frequent Iron Chef judge. I'm personally disappointed.

http://www.msgeek.org/ -- Because you can't keep a geek grrl down!

Finally a voice of sanity (3)

SquadBoy (167263) | more than 13 years ago | (#449462)

in the vi vs. Emacs deal. I have to agree. As a sysadmin type I also make the choice based on a couple of other factors. Over a slow SSH connection vi is faster and feels more responsive.The same goes for editing a couple of lines in a config file. But if I have to edit something long or more then a few lines I find Emacs to better suit my style of working (this is somewhat because I learned a evil editor in my youth and did not see how good vi was untill the last year or so.)

Re:Default shells (2)

duffbeer703 (177751) | more than 13 years ago | (#449463)


The default shell in both Solaris 2.6 and 2.7 is /sbin/sh for root and /bin/sh for other users.

Maybe your site used csh, but Solaris gives you sh out of the box.

Proving once again (2)

Fervent (178271) | more than 13 years ago | (#449464)

That advocacy for something as silly as text shells is an ugly thing.

Let's go New Jersey Devils! :)

Re:This was empirically proven... (1)

Bingo Foo (179380) | more than 13 years ago | (#449465)

There was a fair amount of trash talk on Slashdot before the event. Mind you, these were the early days of Slashdot, and most readers had actually used both [vi and emacs].

I can see it now: The big trash-talk flamewars of the future will be gedit vs. kedit.

Bingo Foo


UNIX commands in Perl (4)

Erasmus Darwin (183180) | more than 13 years ago | (#449467)

Even perl programmers often miss the point, writing the heart and soul of the application as perl script without making use of the UNIX toolkit.

I'm not quite sure what to make of his quote above. On one hand, I freely admit that I tend to think in terms of globbing various UNIX commands together to produce some pretty decent results with the use of just a few pipe symbols as glue.

On the other hand, I feel that doing so in anything intended to be portable and/or robust is just asking for grief. When I stick to utilizing constructs that exist only within perl, I know I'm pretty safe. As soon as I start integrating external commands, I have to worry about checking return values, checking that the command even exists, escaping shell metacharacters, portability issues, and so forth. Some times, it just becomes simpler to "reinvent the wheel", so that I've got a nice, predictable function to deal with.

That being said, for quick hacks that are't mission critical, external UNIX commands are quite definitely the way to go. However, there often is a valid reason not to go that route.

Re:Finally a voice of sanity (1)

mkcmkc (197982) | more than 13 years ago | (#449468)

Over a slow SSH connection vi is faster and feels more responsive.

Huh? Both editors do more-or-less optimal screen redrawing. Why would emacs be slower than vi over ssh (as opposed to the innate difference, which would be present for any terminal)?


Korn and Coors (3)

update() (217397) | more than 13 years ago | (#449470)

So Korn (the band) drinks Coors Light? I might have suspected...

For those of you wondering where that apparently idiotic non-sequitur came from, it refers to this picture [att.com] on David Korn's web site. Roblimo, I appreciate your including my question but you could have edited out that line, especially if you're stripping out the HTML. ;-)

Re:I'm very stupid, please explain (1)

mojo-raisin (223411) | more than 13 years ago | (#449472)

There are some wierd pictures of the pudgy nerd hanging out with the dreadlocked wierdos.

Remember: "i" before "e" except after "c" except for the word "weird."

Re:KSH / other ATT tools not Free? (2)

mojo-raisin (223411) | more than 13 years ago | (#449473)

It is not an acceptable license due to these statements from the faq:
5.Can I modify the source and distribute it to someone else?

Yes, but you need to package the modifications separately, usually as a patch file.

6.Why must the original source be kept separate?

We want everyone who receives the source to know what we have done vs. what changes have been done by others that we have not yet approved. This is primarily an issue of quality assurance.

Put bluntly, only paranoid control freaks put these type of clauses in their licenses (which is probably AT&T's fault). Nobody ever wants to work with such software because of the hoops you have to jump through to improve and maintain it.

Re:"vi is better than emacs" - nope (3)

mojo-raisin (223411) | more than 13 years ago | (#449474)

Once you become aware of the truth that emacs is an operating system and that lisp commands are your "unix tools" you will see the true light.

Emacs makes all other editors worthless.

Re:"vi is better than emacs" (2)

triticale (227516) | more than 13 years ago | (#449476)

What he actually said is that vi is better suited to his style of computer use and therefore what he chooses to use.

Posting your conclusion as a quote is the same type of evil as saying "the Wall Street Journal said George W's Social Security plan does not add up" without including the information that they also said it delays the collapse of Social Security by only a few years compared to Al Gore's, and the alternative savings plan could not be counted on to take up all the slack.

I'm very stupid, please explain (1)

OlympicSponsor (236309) | more than 13 years ago | (#449477)

Call me Ishmael, but I'm still confused: Is there or is there not an actual connection between Korn the shell and Korn (with a backwards "r") the band?
MailOne [openone.com]

My prompt in ksh (1)

westrick (245730) | more than 13 years ago | (#449478)

PS1=`uname -n`':${PWD#$OLDPWD/}$ ' Just enough info about where I am, without wasting the entire screen with $PWD.

Clearing up a common misconception (2)

sparcv9 (253182) | more than 13 years ago | (#449479)

Actually, that's what /sbin is for. Solaris uses /sbin/sh as root's shell and for executing init scripts. (init even goes so far as to ignore whatever #! shell you stick on the first line and uses /sbin/sh) The 's' in sbin stands for static and not 'secure', like most people seem to think. It's where you put your critical statically-linked binaries so that you can use them (like the parent poster noted) if you lose your ability to link/access shared libraries. I don't know how many times I've seen binaries get put in [/usr[/local]]/sbin because they were suid/sgid root or were daemons that attached to priveliged ports or the like.

Wrong! (1)

metlin (258108) | more than 13 years ago | (#449480)

1024 Bytes = 1 Kilo Byte 1024 Kilobytes = 1 Megabyte Sheesh!!!

"...Fear the people who fear your computer"

Yay! Another Shell (1)

Windplume (262613) | more than 13 years ago | (#449481)

Thanks to whoever submitted this. I wasen't aware of ksh93, and will now need to add it to my collection of shells, moving toward my ultimate goal of having every shell on my box.

Re:GUI environment shell (2)

Windplume (262613) | more than 13 years ago | (#449482)

Probably crack. But I bet it would be doable, though I doubt it would be like a normal shell. It would be nice to have...

Re:I'm very stupid, please explain (3)

banuaba (308937) | more than 13 years ago | (#449486)

There is, in a vague sort of way. There was some incedent a couple of years ago where they somehow met (David Korn and KoRn) and laughed it up.
There are some wierd pictures of the pudgy nerd hanging out with the dreadlocked wierdos. Look at this [kornshell.com] for pictures of the band and david and wierdo fans.

Hope that helps,

Re:The place to get ksh93? (1)

bumperson (309668) | more than 13 years ago | (#449487)

http://www.kornshell.com is your best bet, under the "Software" section. Sam

Re:I would outright disagree with most statements (1)

Buckaduck (311846) | more than 13 years ago | (#449488)

No, the reason that perl programmers [...] tend to avoid calling external programs, or call them through modules, is twofold. First of all, those programs, while fairly small, still may do much more than you want to do...

The other issue, of course, is that I don't care to deal with interpreting the output of another command...

I can think of even more reasons why Perl programmers tend to avoid using the UNIX toolkit from within their code:

  • Why should we suffer the performance penalty of creating a child process if we can achieve the same functionality in Perl itself? (Don't we pay enough of a penalty when we start the Perl interpreter itself?)
  • We all like our code to be as portable as possible (as David Korn seems to agree). The UNIX toolkit may be portable from one UNIX to another (pretty much, anyway) but not when you port your code to Windows, MacOS, etc. If we keep our code in one "monolithic" Perl program, we can usually count on it being portable to nearly any operating system. Assuming it was written in a portable fashion to begin with, which is admittedly not all that common.

nice red-eye effect (1)

capoccia (312092) | more than 13 years ago | (#449489)

i think it's pretty funny that the fans of this band look like crazed vampires in the first picture.

Re:Korn Shell question (1)

cecooke (313766) | more than 13 years ago | (#449490)

# More to the point, thanks to the way ksh works, you can do this:

# make an array, words, local to the current function
typeset -A words

# read a full line
read line

# split the line into words
echo "$line" | read -A words

# Now you can access the line either word-wise or string-wise - useful if you want to, say, check for a command as the Nth parameter,
# but also keep formatting of the other parameters...

Re:what would you like to see? (1)

$eyeB0rq_munqee (313802) | more than 13 years ago | (#449491)

mad? why would I get mad if I can just go and make a new account? duh!

not to mention, that would be quite a silly thing to get mad about. maybe I just enjoy getting banned alot?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account