Slashdot Mirror
Unix Shell Programming, Third Edition
Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts. For these we could best go back to the old ways. Combining the power of the common Unix tools, pipes and scripts in a fairly obscure and slightly arcane syntax is not easy to pick up, though the language's simplicity does, in some ways, make it easier than more complex ones such as Perl. This book does a good job at introducing shell programming and I found it an excellent book when I needed a refresher.
I don't want to sell this volume short: you won't just learn about shell programming. The first ninety or so pages provide an excellent guide to getting the best out of the shell, and the last chapter is devoted to the features specific to an interactive shell such as command-line editing and using the history.
The authors have chosen to use the POSIX standard Bourne shell ('bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell.
The book is well structured, starting out with a brief look at *nix operating systems before introducing the shell followed by some basic tools; cut, paste, sed, tr, grep, sort and uniq. One minor quibble, the book explains how to redirect STDOUT to a file and STDERR to a file, but not how to redirect both to the same file. That aside, these few chapters provide a good introduction to the shell.
The text goes on to systematically explore shell programming starting with variables and arithmetic. The chapters are kept short, in a good order and have a number of exercises at the end of each. The structure of the book and the order each new concept is introduced is well thought out; at each stage small examples are given that only use material already introduced and are complete in performing a task. In early chapters they are fairly trivial but by the end there is a fairly complete rolodex program written in shell script that would be a good model for anything you wished to do.
There is also a good summary of the shell syntax and common commands in Appendix A and good 'Further Information' in Appendix B. Kudos must go to the authors for a list of books for further reading that is not ashamed of mentioning other publishers, indeed they say "One of the best sources of books on Unix-related topics is O'Reilly and Associates" and list volumes from them before mentioning their own publishers.
There are some small typographic errors in the text but I did not find any in the script examples I tried. I found it to be well written and readable throughout, perhaps an advantage of a third edition in a slow moving technology.
You can visit the Sams web page devoted to the book which has the Table of Contents and the third chapter available for download. It has no errata or source code, I looked to see if the authors maintained a site for the book but could not find one.
I would recommend everyone read this book once or twice, it provides a comprehensive, well written tutorial on one of the most basic (and often overlooked) tools at your disposal. Even Windows users could install Cygwin and gain the benefit of a good POSIX compliant shell and this book. It also has the advantage that once purchased it will be useful for many, many years to come - the language has not changed noticeably in twenty five years and should not change in another twenty five.
You can purchase Unix Shell Programming, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
JPSoft makes 4UNIX.
Shell scripting is a Lost Art. You know the True Gurus in the IT department by how comfortable they are with shell scripting. And of course, in the world of Microsoft, now one knows what you're talking about when you talk about scripting, they assume VBScript (the language of virii).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts.
Now that machines are getting much faster, can we expect shell scripting to be totally forgotten and unused? Are there movements for this already?
Froogle Link
Amazon Link
Maybe Darl could give a free copy away with every SCO-Linux license he sells....
Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
IIRC, Kochan wrote a prety good ANSI C textbook.
As the risk of being flamebait here, Bash is not the default shell on *BSDs (Is this the reason its dying?), its tsch. Neither is it the deault shell on QNX (ksh is). Perhaps the statement that bash is the default shell on most system seems overly broad.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
I use shell scripts for many things under Windows using the free version of many Unix utilities found HERE. Scripts are fast, and don't break (short of being over-written). Many times, scripts can be written that perform the functionality of expensive Windows programs, with the advantages of being free, not easily broken, and not subject to dll version issues, continual upgrades, etc, etc, etc.
Shell Scripts are really The Cat's Pajamas.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
When I first started learning about the concept of shells, I was moving from the MSDOS world.
One of the first things I remember reading was the FAQ describing the shell differences.
Imagine my surprise that the command line could hold so much control and there were other aspects of controlling a PC. I haven't looked back since, but that page really brings back some memories.
It's funny how something you read can cause one of those lightbulb moments.
Back when dinosaurs roamed the earth and NCR made Unix computers
I used to work on an AT&T 3b2. I can also script pretty well in DCL. Does that make me a sleestak?
Extra points for anyone younger than 30 who can prove they actually know DCL. Demonstrate something good - maybe set up IPC using mailboxes or something.
I cannot tell if you are being sarcastic, but it's pretty easy to see that his comment was, well, sarcastic, making fun of others that use the word.
Scripting was used as a term for the code of the 1960s Terry Winograd robot SHRDLU, that would reason about geometric objects.
Shell scripting is not the same as command line. Yes, many tasks that one does on the command line can now be done in a more friendly way with GUI, but shell scripting != command line. Think of the word "scripting" and what this means: A task that requires some steps, and my possibly be carried out automatically (perhaps with cron or some other daemon...). I would say something rude and stupid like "go back to your Win box and rejoice in your ignorance", but I probably shouldn't.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
The LDP includes the "Advanced Bash-Scripting Guide" which is available in both HTML and PDF (1MB!) formats, and there is even a version for PalmOS! Since I found it, it's been the only reference I've *ever* needed when I've stumbled over some obscure nuance of shell scripting.
UNIX? They're not even circumcised! Savages!
It might help you with that "unemployed" thing you got going on...
You must be trying to do for sarcasm what Alanis Morrissette did for irony.
the language has not changed noticeably in twenty five years (just like CmdrTaco and his underwear!) and should not change in another twenty five.
Clever monkey.
Patrick's research staff contacted me two years ago and I did some minor work for him, via email (I never met him so don't go all crazy and ask for details) and was paid very well, considering it was research for a book.
Patrick's a pretty sharp guy but he outsources a lot of his research to proffesionals (makes sense) and has several staff people help him put the pieces together, as it were.
I offered my services as part of the FTEST (final tech editing service team) but Patrick didn't want a publishing pundit as much as he was looking for computer pundits. Ah well, at least now I'm in his rolodex and hopefully I'll get more chances to work with him.
Warmest regards,
--Jack
The one Amazon.com review gave this book 4 stars.
Helevius
I make my living as a Unix sysadmin, to support my hobby as a Real Programmer :-p.
Without shell scripts, I'd be lost.
Shell scripts provide the ability to leverage the work of every well-behaved perl (etc.) script, binary in /bin, and other shell script ever written. While the same can be said for perl scripts (which I happily use or write when needed), with shell scripting this is the intended paradigm.
Scripts are intrinsically open source, even if copyrighted and under a closed license. The techniques are visible, and thus instructive.
Given Unix's design attribute of easy process creation, shell scripting is often the best way for me to handle a task.
See some examples here.
sigs, as if you care.
The quote for this page when I loaded it:
"It is easier to port a shell than a shell script." -- Larry Wall
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
A virus can be written in any language. Saying that VBScript is "the language of virii" just goes to show your fanboy-ism. Also, don't equate IT gurus by their shell scripting capabilities. I'd much rather write general tasks in Ruby or Perl than that hackjob, ugly-ass shell language anyday.
I cannot tell if you are being sarcastic, but it's pretty easy to see that his comment was, well, sarcastic, making fun of others that use the word.
I find it offensive. You may find it sarcastic, but it is still inappropriate, rude, and insulting. Cowboy Neal should change it, at least put a couple of **'s in there. We would still know who he is talking about, and it would be much more civilized.
I was just mourning the fact that the internet wayback machine's archives didn't include the collection of VMS .COM files I had set up on our campus's VMS cluster. (Running OSU's webserver for VMS)
Unfortunately, it's almost all left me, though I suppose I could still puzzle out the quoting rules to pass quoted arguments down three levels of @-signing. (Doubling the quotes each time...)
And hey, _I'm_ still under thirty (for two more years...)
Just because many shell scripts are hack jobs does not mean that this is the way they need to be. So, are you telling me that all Perl and Ruby looks like it should be put in the Louvre ? Sounds to me like either you don't know how to shell script, or you don't know how to shell script well .
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
I'm a stupid 13-year-old white boy from Utah! My mommy won't let me say naughty words out loud so I go on the interweb and post PEE PEE POO POO DOODY HEAD words, then I go giggle like the little skidmark I am! OMG I AM SO TEH FUNNEY ROFFLES
Do NOT click the Amazon.com link in the parent poster's message! It is a dirty trick! Instead of going to Amazon like I wanted it went to this site called "www.tubgirl.com" and it shows this AWFUL and DISGUSTING picture of a lady pooping all over herself! It is WAY GROSS, DO NOT click that link! Why doesn't Rob Malda BAN such bad people from this site? It is so mean to link to nasty pictures like that!
That works just fine until some update to readline, or ncurses, or any of the other libraries the monster that is bash depends on happens to break your shell. Then, you're off to alternate boot media.
/bin/sh.
/bin/sh and a secondary root login that uses that shell.
It's fine to have bash as your everyday user shell. It's even ok to have it as your default shell for root, though having a second uid 0 login with some more minimal shell (like ash, for example) is often a good idea. However, I wouldn't make it as absolutely essential for the system as it is when it's
Personally, I take advantage of the setup provided by the Debian package sash, which provides a statically linked shell for
bookpool
"('bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell."
Once you move to real UNIX platforms, Solaris and BSD for example, bash is never the default shell, and rarely does it even come with the system.
UNIX(r) Shell Programming, 4th Edition
Of the same name, not related. Go figure. I got both and the one above is the better of the two, IMHO. Chapter 5 of this one is golden, lots of simple tables covering built in operaters, varibles, and control structures.
I really did not GET programming until the book above, it made it click for me. Perl came right after, as this got the concepts in my thick head.
A shell-less admin is a useless as a mermaid, and not as pretty to look at.
Never answer an anonymous letter. - Yogi Berra
Is it coincidence that the quote at the bottom of this page currently is:
"It is easier to port a shell than a shell script." -- Larry Wall
?
What's the point in writing scripts in sh anyway? These days you can use more powerful and less fragile languages like Python. Shells have crappy error handling, complex escaping rules and generally they create more problems than they solve.
In Python, you can easily read the contents of executing programs popen, and likewise write the processed output to other processes also via popen. More facilities exist for error handling, logging and other general "growth" paths of the scripts.
Choosing to write something over 4 lines in a shell scripting language (sh) is a sign of incomptence, nothing else. Sysadmin should still IMO be competent enough to grok more structured languages like Python. It's not the windows world after all...
Sysadmins should also be responsible enough to consider that someone might want to edit the script after him. Shell scripts tend to break w/ editing.
Moderators: reply instead of modding down. Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology still has uses. History alone doesn't warrant it.
UserLinux is IMHO taking the right road, in suggesting that scripts be written in Python.
Save your wrists today - switch to Dvorak
But apparently, you don't believe your own words enough to use your actual Slashdot account. This is the result of small testicals, but if you see a doctor, you may be able to get help.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
And, after all, the article said that the book focused on /bin/sh, not bash.
/bin/sh. That's why startup scripts are written in /bin/sh - because it's always there.
And every unix system has some sort of
But these days as soon as I need a conditional or a loop I start thinking about doing the task in Perl or Python. These languages are so much easier to read and let you fork a process if you need to dip down into the shell.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Why do you assume I have an account in the first place? Slashdot does not require one to post. Second, you may want to see a mental health professional if you associate other people's scripting language preferences with their testicles (and you assume I'm male to boot which, granted, on this site is usually a given but still...)
I find it offensive. You may find it sarcastic, but it is still inappropriate, rude, and insulting. Cowboy Neal should change it, at least put a couple of **'s in there. We would still know who he is talking about, and it would be much more civilized.
I find your taking offense at his comment offensive. Now please go and change your standards to suit my fragile ego as you expect me to do for yours. While you're at it, please take a poll of everybody's standards of offense and modify your speech and behavior appropriately so that you will cause no offense to anyone. That way, society will be much more civilized when you can no longer do or say anything, right?
Unless it's racism against Jews or whites, then it seems to be perfectly acceptable, even encouraged.
$(( is valuable in inner loops when spawning eval repeatedly can slow down a scan of files in a list, etc. etc.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
It should be modded "Redundant".
Everyone here already knows that Malda hasn't changed his underwear in 25 years.
And free as in beer:
Advanced Bash-Scripting Guide
Never ascribe to malice that which is adequately explained by incompetence.
What is wrong with using php as shell script? I have for windows and linux, and it makes life easier (socket programming, db interface, etc). If someone can point out the errors of my way, I am willing to listen.
My opinion is perl is ugly, haven't tried Python yet though...
I'm sure I'm going to end up being the fiftieth person to note this, but still...bash is not Bourne. bash is the Bourne Again shell. sh is the Bourne shell. bash has many extensions that are not present in the Bourne shell.
/bin/sh does just point to the bash shell, but you can't count on that being the case.
One of my pet peeves is people who'll start a script with #!/bin/sh and then go on to use bash-specific syntax. That is just plain wrong; if you are going to use bash syntax, use #!/usr/bin/bash (or point to the actual location of bash on your system). In many cases
if I recall correctly, the plan for Longhorn is to be able to do ANYTHING from commandline. If it can be tweaked in a GUI, there's a shell command that will do the same thing.
Comment removed based on user account deletion
sh and make are two utilities that frankly would never be succesfully introduced today. We use and accept them because of their incredible legacy presence.
There is no reason why I cannot have a shell language that has all of the functionality and features of python or perl. Yes there are projects to use these languages as true interactive shells but the continued use of sh keeps them from getting steam.
Killing sh and make would be two great steps forward for modernizing unix.
The other day I wrote a little utility to track referrers to my websites. I wrote the main chunk in perl. But the part that actually drives the whole process -- that sifts through config directories, calls child scripts, sends email... right back to bash. It's just so damn easy. Or maybe that's just my distaste for perl talking.
wordclock records
I typically discard shell for anything more complex than a while/do sh loop. For anything moderately complex, sh is baroque, syntactically retarded, and feature-deficient.
Please, tell me what distro does not include perl or python practically by default. This is a silly argument that was irrelevant about four years ago.
...In my imaginary Slashdot fantasy land. We should do lunch sometime.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
If memory concerns are truly an issue, you are not going to get relief by simply switching environments. You probably need to rethink and redesign.
Basically, if you have a *NIX like system, you are pretty much guaranteed to have a /bin/sh, and it will always work the same. Bash is common, but not universal. Ksh is proprietary, though there are open source versions (pdksh), but you won't find it everywhere. Csh is an abomination. Other shells are interesting and useful, but you'll never know if they are on any given system, or if they will run the same.
If you want a script that will run the same everywhere, then use /bin/sh.
(Of course, this isn't even getting into differences between "awk", "nawk", "gawk" and all the other tools and their various incarnations that you end up using in shell scripts, but at least you can have some hope that the underlying shell will be predictable.)
Your Servant, B. Baggins
Please don't mention NCR! It's been almost 3 years since I quit as a field engineer and I still have nightmares...
All of these I can do by hand and on machines where the scripts are borked I do. I then replace the IF WHEN WHILE bits of the scripting language with my brain. In fact that is how I write scripts. I write down into code what I have been doing each time.
So speed of cpu is meaningless. It is all done to help lazy sysadmins.
You might mean, because cpu is more powerfull can't we use other languages. Well yes. There is nothing really stopping you from replacing a lot of shell scripts with say perl. EXCEPT. Perl may not always be there or working. You need something simple and lowlevel for simple and lowlevel tasks. I don't see this changing. Hell MS is talking of adding stuff like this to longhorn.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
When I went to work at HP I was amazed to find the default shell of HPUX to be Ksh (Korn), sort of a Children of the Korn Environment?
Really, there are people at HP in Boise who have thousands of hours of highly useful Ksh Scripts for doing everything from test automation to you name it.
The young folk coming in seem less then enthusiastic about learning Shell Scripting, to bad.
language has not changed noticeably in twenty five years and should not change in another twenty five
Is this a good thing? I mean don't we sometimes have to abandon the ideas of old in order to progress? How has English evolved over the past 50 years? Besides the branch of American English and the ones the UK speaks and writes. Maybe not much but how about 300 years? As technology progresses further than a Moore breaking speed should the language not evolve as well?
I agree that Unix language is solid and has been around for a while, but should we choose the permanent language based on technology first conceived 25 years ago?
This SIG pulled due to lack of funding. (This damn war is costing too much!)
I don't know what "practically by default" is supposed to mean, but I'll tell you what Unices (even beyond your Linux "distros") don't have Perl or Python: the ones where /usr is unavailable at the time you need to do something.
When I was a kid, we only had one Darth.
Reading through this thread, I am wondering- am I the only one who uses shell scripts, then breaks into perl whenever something more complicated is needed?
Sure, you can do everything with awk and sed if you want to, but having perl -e in the middle of all those pipes is not a sin, and it makes otherwise tedious proccesses go by quickly.
-- 'The' Lord and Master Bitman On High, Master Of All
Get black people to stop using that word, then we'll talk. The notion that only certain people can use that word is racist too.
I think Niklaus Wirth would be interested to hear that Bill Joy was the creator of Pascal...
I'm off to the pub. Happy New Year all!
Toby Poynder
London, UK
Another (free) resource is the very readable, very thorough Advanced Bash-Scripting Guide [http://www.tldp.org/LDP/abs/html/]. Mendel Cooper has done an excellent job with this project. If a person wished to learn more about Bash, I would direct them here *first*.
Personally, I prefer shell scripts due to their ease and speed - most of my scripting is of the "I have N tons of data, find some piece of information & correlation" type. If I'm automating tasks, I'll use a shell script to tie together a series of perl & expect scripts...
Need Geek Rock? Try The Franchise!
Here's a clue: there's more to *nix than Linux.
But the question really is, which flavors of Unix have both Perl and Python installed by default. Once can count on having the Bourne shell (or something compatible) on virtually any Unix installation. If one is to target Perl or Python, one cannot count on it being there.
Windows NT scripting is "very functional" but Perl is bloat. Wow, funniest thing I've heard all year.
"The world only exists in your eyes. You can make it as big or as small as you want." - F Scott Fitzgerald
1) opening files for reading and writing by file descriptor
2) merging and splitting file descriptors
3) field separators, quoting, and globing
4) handling whitespace and empty variables in tests without getting syntax errors
5) signal handling
6) semantics of subprocesses (when do variable or env variable changes become visible, if ever, etc.)
Why is Slashdot centering the text in my post?
NetBSD.
Constitutionally Correct
Steve Bourne calls them shell procedures not shell scripts. I figure since he created the shell named after him, he should know. So I call them that too.
I was thinking of ( ), not { }. ( ) opens a subshell; { } runs in the current shell (which has its own interesting effects).
All the comments about how powerfull shell scripting is, miss an important point:
The vast majority of shell scripts rely on other commands to do alot of the work. For example, how many shell scripts use awk, sed, find, cut, head, tail and so on. Without all the "external" commands the shell is much less useful.
In addition, there is considerable overhead due to the fork/exec of these external commands.
With languages like perl/python/ruby you may have to actually write a little more but it all executes within a single process.
comm'on Perl is under 1MB. in the 90 that was'nt bloatet.
Here's a script for that nicely written post. Happy New Year!
e `whoami`
GET http://www.perfidious.org/award|\
sed '1!G;h;$!d'|sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//'|\
writ
MoFscker
Ok, I have a question. My ISP uses bash and when you tab complete stuff it automagically encloses it in double quotes. But when I tab complete on my own box it just does the old insert\ back\ slashes which is kind of lame.
So, I figure it must be some sort of option I can change in bashrc or something but I don't know what needs to be changed or added for this to occur.
My Minix box doesn't have perl or python.
No room for that kind of bloat. The entire install media set, including all source, fits on 9 floppies.
A Good Intro to NetBS
I found more reviews at verygeekybooks.com. Here is the link.
A referral link, but definitely not a tubgirl link.
I agree that racism is intolerable. However, my response was directed at a comment I read that implied that the blog was intentionally promoting racism.
I read his blog entry as an illustration of how awful some posters are. While perhaps he could have worded it a bit better, it still sounded to me as if his blog implied that people who post racist comments are the lowest of the low, the people that "gotta piss in the pool".
I guess that means that you've yet to have any sort of job in the IT industry.
When I see someone who finds themselves
constantly dipping into awk and sed when
doing shell programming it tells me that
they don't know much about shell programming.
Go learn ksh93 inside and out and you won't
have to do this. Same goes for people who
think that the shell is "just" for tying
together all those Perl and Python scripts.
Maybe a good example of how shell scripting can be made to good use is smartadmin, which i wrote during a weekend :
ftp://ftp.crashrecovery.org/pub/linux/smartadmin/
smartadmin - Create/Edit/Remove a UNIX/Linux user and/or a Samba user.
smartadmin was created out of sheer misgrief about total contra produc-
tive effects of packages like webmin, requiring rediculous resources to
perform basic user administration on a UNIX/Linux and Samba server. The
requirements for smartadmin to act as remote admin is just a terminal
client program which can handle ncurses/dialog menu's.
in my life God comes first.... but Linux is pretty high after that
Francis Smit
Perl and Python introduce possible security holes, as they have all sorts of modules and add-ons that might not be secure. The shell is well-understood, hasn't changed in decades, and (unlike Perl or Python) is a required part of any Unix system (although for the truly security conscious, you might want to ditch the shell as well if you can get away with it).
Please, tell me what embedded distro includes perl or python practically by default. Always wanted a few extra scripting languages on a 4 MB ROM. Right.
lol you are badass little fuckwit...your site is fucking retarded. How can't you be embarassed to live for God's sakes?
ah well, maybe you'll be shot in a botched bank robbery or something...later fag
When the Junior Unix Sysadmin comes to me, as they do, and asks "what language should I write this tool in?", here is my decision sequence:
- shell (with sed/awk/grep) for process management/job control and line-by-line text processing.
- C for servers, time-sensitive applications, interfaces to syscalls.
- Python or Ruby for complex system tools that benefit from an object model.
- Perl for text mangling. I know; Perl can do anything, and often it's the fastest to write. But as the corollary has it: in Perl, there are too many ways to do it. I usually say that "Using Perl for any of the above is cheating," but what I actually mean is that since most of the perl I've seen produced by anyone below "Guru" status is sloppy, undisciplined, inconsistent and barely maintainable, I'd rather see the above languages used instead.
- Java for the server-side of big business applications (i.e. Java is the new COBOL)
- C++ when Java is too slow or memory hungry, or for client-side business apps (e.g. GUIs, office software, the recording backend for your particle accelerator)
This list, in this order of preference, has stood me in good stead for years and leads to decisions that are almost always right.I never recommend TCL or expect, believing them obsoleted by python/ruby. LISP is only a good recommendation for emacs weenies, who live in their own wonderful world and never ask others anyway.
Sorry, no, PHP doesn't qualify as a useful language in my book. I see it as an API the size of a planet driven by a syntax akin to a small, sick dog. Vade retro.
- J
The shell-like scripting languages are actually a lot closer fit to their problem domain (managing programs, I/O, and files) than more recent scripting languages like Perl and Python. There are a number of reasons for their decline in popularity, but it is hard to argue that explicit management of files and their contents (open, close, iteration) is easier or better than piping and redirection. It is also possible to make shell-like languages both faster and safer than other scripting languages (this is work in progress - I hope to make a prototype release available soon). Although it may surprise many Slashdot readers to hear that bash is easily 10 times faster than Perl for many text processing tasks...
Once upon a time I had some nasty .BAT files that used AWK.EXE and SED.EXE for the heavy lifting. Explaining them to a coworker took a while, because he wasn't an awk or sed guy.
.BAT files are very limited, and annoying. VBscript/WSH syntax is verbose and annoying. Shell syntax is just plain fucked up and annoying.
WSH is complex, but nontrivial shell scripts are complex too, there's a lot of baggage involved.
I'm an equal opportunity bigot: I hate all the common scripting choices.
The above have their place, and I can write scripts in all of 'em, but I don't enjoy it.
When possible I lean on awk/sed/Perl. The DJGPP AWK.EXE and SED.EXE has saved my bacon many times, and these days Perl runs nicely on Win32.
Ah, yes, the standard argument used by racists to defend the indefensible.
except that awk and sed tend to be the same no matter what shell you're using
-- 'The' Lord and Master Bitman On High, Master Of All
But, I'm also pretty certain that this is a minority position. Most Unix boxes are purchased/leased for a specific purpose and the default install contains very little leaving the administrator to decide which programs to install. The fewer programs installed, the fewer possibilities there are for something to go wrong.
I hold that this is a good thing because the administrator knows better if Perl (or Python) is needed and if so if Perl (or Python) needs to be a specific version or flavor or compiled with specific options and so on and so forth. It is best to keep the defaults to a minimum and assume that the adminstrator knows what to add on and what not to.
Hence, your beef seems to me to be with sys admins that aren't providing the tools that the boxes they installed need for the users to get their work done. It doesn't really have anything to do with whether or not a given toolset is part of the default install.
Although, I will also say that it royally pisses me off when the sys admin installs one of the newfangled versions of vi with all the bells and whistles turned on so that I have to edit some .rc file or the other to turn them off so that vi acts like vi. When I want syntax highlighting and autoindent, I'll use xemacs. Few things are more irritating than discovering pasting a sizeable chunk of code only to discover that vi is actually vim and autoindent is turned and all the indentation in twenty lines or so of code you just pasted gets funged because vim's autoindent sucks when the pasting lines already indented.
Whatever. This book is no substitute for a close reading of The Unix Programming Environment -- if anyone knows what is, I'd love to hear about it.