David Korn Tells All 118
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?
Thanks.
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:
- Associative arrays - ksh88 already supports indexed arrays.
- Floating point arithmetic + math library functions.
- Arithmetic for command similar to C and awk.
- Complete ANSI C printf formatting with extensions.
- Run time linking of libraries and builtins.
- A number of additional substring operations such as offset length.
- Full extended regular expression matching capabilities
- Compound variables which can be used to represent data aggregates.
- Name references for passing aggregate variables by name.
- Active variables. Users can trap variable assignment and references by associating intercept functions of the form name.get and name.set.
- Ability to make socket connections to servers by name.
- read with timeouts.
- Conformance to POSIX 1003.2.
- Command completion and variable completion, ksh93 only had file name completion.
- A key binding mechanism that allows users to bind keys to new editing functions.
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:
- Floating point arithmetic.
- 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.
- 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.
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.
Thanks,
-Dom
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:
Peter,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!
Best,
Adam
Our thanks to David for his responses, and likewise to Adam for his.
Re:"vi is better than emacs" (Score:1)
Heck, I thought Emacs was a state.
Oh my god (Score:1)
Oh, the humanity !!!
Re:Experiences with UWIN (Score:1)
Silly fool (Score:2)
Only one problem: It was invented at AT&T Bell Labs in the early 1970's, and implemented as a research testbed called "Unix".
Yeah, today's component-oriented programming uses structs and RPC rather than streams. But it's the same darned thing. In fact, I recently architected a commercial tape backup program as a series of what is basically Python scripts being run as remote commands via a specialized RPC server. It made things *MUCH* easier to test, because I could run them locally (on the tape server, without going through the RPC service) as individual commands with some test inputs and outputs, and thus verify correct operation prior to attempting to connect to them from the client.
If you get a chance, I hid a file called 'TECHFAQ' in the Docs directory on the BRU Professional CD that explains more about the Unix philosophy and how well it applies to The Real World (as vs. to your Microsoft-centric world of threads and sending structs via RPC). I explain the performance disadvantages (minimal), the reliability advantages (extreme), and otherwise talk about The Unix Way (I say I "hid" the file there because until now, I haven't told anybody outside the company that it was there, and it's otherwise buried in a mass of .html files :-).
BTW, this program was written in Python, and makes extensive use of Python's class system and introspection facilities (especially for the subclasses of the master "dbrec" class, many subclasses are about 10 lines long of dbms record definition and that's it). But that does not invalidate the Unix model, but merely extends it.
-E
Re:*shudder*... (Score:1)
And thanks for the link about ed. That was hilarious.
Geoff
Unable to compete? (Score:1)
Quite the reverse...
Re:This was empirically proven... (Score:4)
Re:BBEdit all the way, BAY-BEE!!!!! (Score:2)
Re:This was empirically proven... (Score:2)
Anyway, "vi" is the heart of "evil".
Re:Executable sizes (Score:2)
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com
Re:Default shells (Score:1)
--
Re:Korn Shell question (Score:2)
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".
--
Re:UNIX commands in Perl (Score:2)
I'm *forever* using Perl for this. Anything where the natural shell approach would be 'cat file | x | y | z', and (say) z is something that is not obviously achievable with an existing UNIX tool.
Thing is, it usually turns out there's *is* an easy way to to z with a standard UNIX tool: only the other day someone pointed out to me that I'd reimplemented 'uniq -c' in Perl. At the time I was unaware of the -c flag to uniq.
--
Korn Shell question (Score:4)
Consider this code:
x="hello"
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 (Score:1)
Must be progress.
Regards
Re:Korn Shell question (Score:1)
My feeling is that shells should expand wildcards regardless.
regards
Re:So which OSen have ksh93 installed by default? (Score:1)
Re:Default shells (Score:2)
This was empirically proven... (Score:2)
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.
Lenny
Nostalgia (Score:1)
-- Brian
Re:GUI environment shell (Score:1)
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. . . (Score:1)
** Martin
Re:Executable sizes - uh. re-read that. (Score:1)
sheesh
** Martin
Re:So which OSen have ksh93 installed by default? (Score:1)
all ya gotta do is cd there and type make install clean
Re:Korn Shell question (Score:1)
Hmm
Macka
bash is broken (Score:1)
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.
Macka
"vi is better than emacs" (Score:4)
(blast shileds deployed)
Re:UNIX commands in Perl (Score:1)
Re:Executable sizes (Score:2)
I would outright disagree with most statements (Score:2)
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 (Score:1)
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!
if ( -x /usr/local/bin/ksh ) exec /usr/local/bin/ksh /usr/local/bin/bash ) exec /usr/local/bin/bash
if ( -x
Re:Default shells (Score:2)
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*... (Score:1)
-lx
CGI's using a shell (Score:2)
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 (Score:1)
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
-josh
Old ideas (Score:3)
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?
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.
-josh
I'm surprised that nobody has brought up (Score:1)
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.)
(jfb)
Re:Korn Shell question (Score:1)
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:*shudder*... (Score:1)
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!!
And if you really want UNIX commands in Perl... (Score:2)
Check out "Perl Power Tools: The Unix Reconstruction Project, [perl.com]" where many of the Unix utilities have been written in Perl. In addition to being kinda neat, they make for good mini tutorials for Perl. So far there are implementations for:
Cheers,
Re:Korn Shell question (Score:2)
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 -- $stringx=$1; shift
y=$1; shift
junk="$*"
I have to agree, though, that the ksh implementation is better.
So which OSen have ksh93 installed by default? (Score:2)
---
Re:*shudder*... (Score:1)
While quite to the point, I would advance this shell as more fitting: c:\windows\progman.exe.
--
Re:*shudder*... (Score:1)
--
Fix the damn BOLD tag! (Score:1)
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
Re:*shudder*... (Score:1)
Resigning me to progman.exe for my naivety is just plain cruel!
:)
--
Re:So which OSen have ksh93 installed by default? (Score:1)
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? (Score:1)
Equality (Score:2)
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 (Score:5)
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
Re: (Score:2)
Re:GUI environment shell (Score:4)
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! (Score:2)
they have a
how sad that our fearsome ahem
Re:Finally a voice of sanity (Score:1)
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? (Score:1)
In vi editing mode, type ESC Ctrl-V
In emacs editing mode, type Ctrl-V
Re:UNIX commands in Perl (Score:2)
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" (Score:1)
Re:Equality (Score:1)
Re:KSH / other ATT tools not Free? (Score:1)
Re:I'm very stupid, please explain (Score:1)
Works every time.
--
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
Re:Finally a voice of sanity (Score:1)
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 (Score:2)
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.
-Ted
Perl is absolutely faster than Ksh: Proof (Score:2)
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.
-Ted
Experiences with UWIN (Score:2)
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.)
-Ted
Sig (Off Topic) (Score:2)
"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."
-Ted
Executable sizes (Score:1)
--
Too stupid to live.
It's one of the best features of ksh vs. /bin/sh (Score:2)
Re:"vi is better than emacs" (Score:1)
vi rules!!!
Re:*shudder*... (Score:1)
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 (Score:1)
Re:Finally a voice of sanity (Score:1)
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 (Score:3)
However here are some of the features I like in tcsh:
- set prompt = "%B%c2%b `whoami`@%m%$shlvl "
- set who = "%B%n%b has %a %l from %M at %t on %w %D."
- set autologout = (120 60)
- set complete = enhance
- set autolist
- set pushdtohome
- 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
- set printexitvalue
- set ignoreeof
- set noclobber
- set rmstar
:-)
- alias cd "cd -v"
/bin/echo ""
- complete cd 'p/1/d/'
- 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!#Custom prompt with the name of the current directory, user and server: very useful for sys admins of many servers with many roles
set watch = (0 any any)
#Watch who is loggin on or off the system and from where
#So you don't accidentally leave terminals/connections open
#Case insensitive completions, ".-_" as word separators, "-" and "_" considered equivalent
#List possibilities on an ambiguous
#Make pushd with no args do a "pushd ~" (like cd does)
#List all jobs when suspending completion
#Print non-zero exit values upon program completion
#Don't kill shell when ^D seen
#Don't overwrite an existing file when using ">"
#Prompt the user before execution of "rm *" !!
alias precmd
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 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.
Re:Finally a voice of sanity (the true answer) (Score:1)
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:Old ideas (Score:1)
It means that I can run tests scripts automatically to ensure that the internal functioning of a program is correct.
I can also automate data processing (just imagine taking those hundreds of simulation runs, doing the data analysis and plotting the results using a point and click interface). At least with a shell script, or perl, or ruby (my fav) you can automate this process - link the simulation tools to the analysis tools to the plotting tools. Even MS does this with VB (although it hust isn't as pretty!).
regards
tree_frog
Re:Korn Shell question (Score:1)
So maybe this trick isn't so safe? Perhaps someday you'll upgrade something and your scripts will stop working.
Re:Default shells (Score:1)
Disclaimer: I hope this doesn't become a shell war thread... :-?
Cheers...
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
*shudder*... (Score:4)
An asumption like this should earn him
Cheers...
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
GUI environment shell (Score:2)
Eg, you could write a script to go searching through a gnome-vfs 'filesystem' or such...
Or am I on crack?
Re:Korn Shell question (Score:4)
Re:I'm very stupid, please explain (Score:1)
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*... (Score:1)
For the first time ever that I use these three letters, its actually literaly true...
LOL
Thank you
Re:So which OSen have ksh93 installed by default? (Score:1)
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:Default shells (Score:1)
Re:I would outright disagree with most statements (Score:1)
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.
What I want to know is, "Faster how?" Startup? Total execution? File handling? Mathematics?
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.
--
ALL YOUR KARMA ARE BELONG TO US
Re:Korn Shell question (Score:1)
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.
-VoR
Re:I'm very stupid, please explain (Score:2)
----
http://www.msgeek.org/ -- Because you can't keep a geek grrl down!
Re:Finally a voice of sanity (Score:1)
Finally a voice of sanity (Score:3)
Re:Default shells (Score:2)
The default shell in both Solaris 2.6 and 2.7 is
Maybe your site used csh, but Solaris gives you sh out of the box.
Proving once again (Score:2)
Let's go New Jersey Devils! :)
Re:This was empirically proven... (Score:1)
I can see it now: The big trash-talk flamewars of the future will be gedit vs. kedit.
Bingo Foo
---
Re:UNIX commands in Perl (Score:2)
I've heard first-hand accounts of people trashing Very Important Files because they accidentally used a '>' instead of a '<'. Piping from cat, while gratuitous, greatly reduces the chance of error. Personally, I'm not gonna lose sleep over the wasted CPU cycles.
UNIX commands in Perl (Score:4)
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.
Korn and Coors (Score:3)
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:KSH / other ATT tools not Free? (Score:2)
---
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 (Score:3)
Emacs makes all other editors worthless.
Re:"vi is better than emacs" (Score:2)
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.
Clearing up a common misconception (Score:2)
Re:GUI environment shell (Score:2)
Re:I'm very stupid, please explain (Score:3)
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,
Brant
Brant