A very attractive and well justified rant. But others, with far more experience but much less aesthetic sense have been barking up that tree for 30 years.
In fact, it's thanks to the lousiness of the Unix shell that we have Perl and TCL, and their progeny, Python and Ruby.
People who need intellectual closure should try SCSH, which unifies the disparate worlds of procedure, builtin, operator, command, socket, file, pipe, process, thread and system call into one coherent construct: function.
Take a look at the manual as well. The quality of technical writing and presentation are the norm in that neck of the woods. Suckage shouldn't be the status-quo. Worse is not better. Evolve!
Lousiness of the unix shell? The shell is beautiful and useful and not in any way lousy. It's not supposed to be a programming language, in fact, the only places it's used as such are places where it's unreasonable to expect a system will have anything else (autoconf and friends).
When's the last time you used perl, tcl, python, ruby, or anything but the shell as an interactive prompt to invoke other programs?
If I may:
filter ()
{
read p && echo $p || exit
while read x; do
if [ `expr $x % $p` != 0 ]; then
echo $x
fi
done | filter
}
Question for you: what is the syntax for declaring a variable, initializing the variable, referencing the variable later, and assigning the value of that variable to another variable? ;-)
Now that I have refreshed your memory, do you still insist it's not lousy?
For the innocent bystanders, here is how those steps are:
set var # just creating the variable .. easy
# but set is a configurable command!
# see your "sh" variety man for more info
set var=value # no space on either side of '='!
# 'value' can only be one word string,
# number or character.
# because single characters are
# ubiquitous in nature ..
# chars chars, everywhere
# if you want a multiword string, use ()
# or "a raw string with spaces"
# unless you want $ not to be expanded
# then use 'raw constant string'
# and if you want to run a program and
# insert its output into the string ..
# use "`program`"
# did I say you can't put spaces around =?
# eskooz me, I am just dereferencing var
set newvar=$var # need a magic syntax, it's teh C ptr
# unless you want the *whole* value
# then you use ($var) or was it $(var)?
# again, ask your sh variety manpage
# I love portability
# if $var isn't bound, use $?var to test
# we said 'set' is a command above
# so using unbound var is ..
# dependant (sic) on settings
# if var contains multiple words (why is that a unit
# of input neway?) you can index it and count elements
# with $#var and $var[i] respectively; we made everything
# an external command or built in, but LENGTH and INDEX
# need to be special syntax, because they're more vital
# than goddamn assignment (which is fine being a builtin)
Again, it is not a programming language. The shell is designed to do things you think about for less than 10 seconds. If you're trying to reference a variable you used earlier, that's not what it's for. You don't store things in the shell. You create very quick and dirty statements to make data look cleaner.
I actually agree with you. If all you use the shell for is to launch programs, do basic job control and redirect I/O and do some basic pipelines, then you should be fine.
But keep in mind that 10s shell solutions becomes week long problems the moment you save them into a file. I have complex commands, either stored in a function or grepped from my history ;-) but my initial response was to the author, and anyone who laments the shell's shortcomings for anything more "industrial" than a one liner. I was strictly answering the premise in the fifth panel:
One-off scripts never are. You reuse them and tweak them for slightly different scenarios, then figure, I'll make it a parameter. Then something goes wrong and you add some error checking. Then you show it to someone else or put it in a cron job or whatever and you write some documentation.
Before you know it, your little script is no only a permanent fixture, but other people are relying on it, or its output, or reusing one of its functions. I've seen 10-line file mungers end up as 1000-line batch jobs.
Well, this is how we got stuck with autoconf (of course, then some genius decided m4 was a good idea). Interestingly, sh (at least, the common intersection of all the shells) is a good choice for a language that needs to bootstrap, since pretty much every unix machine has an implementation installed somewhere by default. The way they used it was a little wonky, and if we could go back in time I'd probably suggest generating the configure script from a better language than m4, but it's not the worst of all possible worlds.
That is a cool link, thanks for sharing! Somewhere there's a similar article with OCaml that I never got all the way through, though maybe it was more about systems programming than system administration (so, replacing C, not sh).
I feel someone should point out that "set" in this usage is a csh thing. The slides and the referenced comment use Bourne-type shells, where "set" is a builtin mostly used to set shell options: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_...
In csh, where using "set" like this would work, you can actually put spaces around the = (go figure).
I'm not aware of () being used for quoting words in any variant of sh or csh.
I cherry-picked the good parts because that's what it was built for. Obviously, misusing it is going to give you a terrible experience, you never answered my question about using another programming language in place of an interactive shell.
Ruby, Python and Perl have even stranger variable behavior (esp. re: scope) and their own mess of ugly sigils (all with entirely different semantics), so I don't know why you're picking on sh variables. True, each different shell has its own intricacies (particularly when you get to arrays), but this matters next to never, when you look across uses of the shell.
Ok so sh is good for small one-off scripts, fair enough. But why? Why shouldn't a sh language be good? Why can't I interface with other programs (that have bindings) natively in an sh? Why is it considered a good thing to make it a complete pain to do anything non-trivial with sh? As for the argument of keeping memory usage low that's a bunch of crap vm's are usually comparable or lower.
Whether or not the shell is good depends (like everything) on what you are trying to do with it.
For an interactive console, I find bash (with the completion package and a custom prompt) better than anything I have ever used (and I keep trying to find a replacement).
For programming, sh is great at matching and moving files en masse depending on a few parameters, or wrapping cron jobs, and the like. For this it is downright delicious, but for things outside its domain, it rather sucks just like any programming language.
You can't click, and there are no next/previous/etc. links. You have to hit space to advance to the next slide.
I discovered this after much pain trying to view it on my phone, subsequently trying to view it in Firefox, then (suspecting it was Webkit-centric), Arora, and I couldn't get past the first slide. I viewed it in w3m, now suspecting Javascript oddness was at fault, and was presented with a list of keystrokes (helpfully hidden by the Javascript that runs when you hit the page). In fact, it doesn't even load the slides (which are all formatted text--HTML! The thing browsers are for viewing!) until the Javascript runs.
From a quick glance at the source, it appears the culprit is some atrocity called "showoff", apparently. It would actually be easier to figure out how to view Powerpoint slides on my phone than it was to figure out how to view this thing.
to be fair, it's meant to help give presentations. it's very specifically designed to not advance on mouse click because that allows you to use your mouse to highlight things on a slide, which I do all the time. You can use arrow keys or spacebar - I always instinctively hit the arrow keys when I see slides online, it honestly never occurred to me that anyone would click and expect the slide to advance.
In fact, it's thanks to the lousiness of the Unix shell that we have Perl and TCL, and their progeny, Python and Ruby.
People who need intellectual closure should try SCSH, which unifies the disparate worlds of procedure, builtin, operator, command, socket, file, pipe, process, thread and system call into one coherent construct: function.
http://www.scsh.net/index.html
Take a look at the manual as well. The quality of technical writing and presentation are the norm in that neck of the woods. Suckage shouldn't be the status-quo. Worse is not better. Evolve!