You know, I keep going back to what I've said before: if it ain't broke, fix it until it is. I think that's the fundamental problem with more than a few pieces of software where the developer(s) continue to enhance something until it becomes if not just unwieldy but so bloated with features that it is unusable.
To my great embarrassment I have done it and I have regretted having done so, particularly when the phone started ringing at 0300.
Some years ago I administered a pair of Perkin-Elmer super mini's. These beasts had to be booted manually on the console and ran a pretty basic operating system. They required 440V 3-phase power and you could heat the building with them. They were, for all practical purposes, about as powerful as your average four function calculator and the happiest day was when they were replaced with a couple of Motorola VME boxes (with 68040 CPU, lots of RAM, lots of disk and SVR4). The important thing being the SVR4 part: that's Unix System V (Linus was still in grade school at the time). I was already a Unix user and administrator and my life got real easy from that point (the user community were also up to speed with Unix so the switchover went smoothly).
The important thing about Unix, then and now, was the philosophy with which Unix was developed; it's in my signature down below here but it bears repeating:
Quote:
Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, summarized the Unix Philosophy as follows:
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
This is usually abridged to "Write programs that do one thing and do it well."
|
SVR4 like all Unix releases followed that philosophy to the letter: do one thing and do it well.
The Bourne Shell dates from Version 7 and is a shell or command-line interpreter for computer operating systems. That, simply and elegantly, is what a shell program is for and does; that's the definition.
Stephen Bourne developed it at Bell Labs and it is still in use in every Unix and Unix-like system (you know, Linux, OSX, etc., etc.) for the simple reason that it does one thing and does it well.
Or is it?
Well, no. Nowadays, at least on Linux systems, it's a link to BASH (Bourne Again Shell) which runs Bourne shell programs as if it were actual
sh as do other shell programs based upon Bourne; e.g., KornShell.
KornShell,
ksh, developed at Bell Labs by David G. Korn, is an interactive command language
and a high-level programming language. It incorporates the best features of the Bourne shell and C shell (developed by Bill Joy at the University of California) and new features of its own. For example, Mike Veach of Bell Labs contributed the original code for the
emacs built-in editor used in the KornShell language and Pat Sullivan, also of Bell Labs, contributed the original code for the
vi built-in editor used in the KornShell language. So, you can do command-line editing with either
emacs or
vi editing codes as you see fit: it's built-in, not an add-on. (This was adapted from Morris I. Bolsky and David G. Korn,
The KornShell Command and Programming Language, Acknowledgements and Preface, ISBN 0-13-516972-0.)
Both Bourne and Korn shells have remained pretty much untouched for... well, a long, long time. They work, they do what they're supposed to and that's that.
BASH was developed at arm's length from scratch. The developers had the function that Bourne and Korn shells had but not the source code (on purpose) and did a pretty good job of it (they may have thrown in a little C shell while they were about it too). You may notice, if you haven't got anything else to do, that pretty much all BASH shell programs will run in KornShell and vice versa. The few trials that I've done bear that out but I haven't done enough testing to really say that it's completely true. There are, however, BASH shell programs that will not, for sure, run in KornShell: those are the ones with "GNU enhancements."
Enhancements is a weasel word for additional features. Enhancements are the things that make other things break all too frequently.
Harsh? Nope, not harsh, more of a warning.
A text editor should edit text. Period. It does not need to be a word processor or formatter or beautifier or whatever it just needs to edit text. Likewise, a shell program should also do one thing and do it well. The current flap with BASH appears, at least to me, to be an enhancement that went terribly wrong. All you have to do is ask yourself if a shell program should do what BASH was doing (and the fix for it looks like an engineering kludge to me). For me, your mileage may vary of course, is no, KornShell doesn't do that and neither should BASH (or any other shell program, dammit).
The company that was using the Perkin-Elmer's did FORTRAN programming under contract. The FORTRAN compiler was, pretty much, IBM's FORTRAN IV (we're talking a long time ago stuff here). The Unix boxes came with ANSI standard FORTRAN 66 (and FORTRAN 77) and we had to port the existing code to at least 66. That meant run the compiler and see what broke and the breaks were all vendor enhancements that had to be rewritten, lots of editing and testing and verifying. Took a while, that. That, among other things, is why I will not ever incorporate vendor enhancements in any code I ever write. GNU tends to enhance now and again (I do port things back and forth between Solaris and Slackware and Sun was just a guilty of enhancing here and there as GNU). Write to ANSI or POSIX standards and you're safe.
I tend to stick with KornShell ("real" KornShell that comes with Slackware (and Solaris)), not any of the "variants" of KornShell (dtksh, tksh, oksh, mksh, SKsh, MKS). I've tried a few, one thing doesn't work the way it should and I'm done with it.
So, could you actually default the system to KornShell rather than BASH? I really don't know (I'm going to set up an isolated Slackware 14.1 and try to find out). How much stuff would break, how much screwing around would it take to get 100% reliability? Easy enough to batch edit every shell program and change the
#!/bin/bash to
#!/bin/ksh, wouldn't have to bother with the
#!/bin/sh, though, just symlink
/bin/sh to
/bin/ksh. Hmm, might be interesting.
But, when Slackware 14.1 becomes 14.2 or 15.0 or whatever you'd just have to do it all over again (and fix whatever doesn't work again).
It turns out to be a conundrum.
Hope this helps some.
