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.
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?
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.
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.
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!
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.
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
?
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.
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Constitutionally Correct
- Every Posix-compliant system has
/bin/sh, but not neccessarily Python or any other interpreter or compiler. Which is the reason why Python comes with a ~20000-line configure script written in sh, not a python-based one even if it probably would be nicer.
- It is the same language you use in an interactive shell. Once you figured out how to do stuff manually, you just have to put the commands you typed in a file together with a shebang line, and there is your script. Knowing shell scripting also helps when working in interactive mode, a loop or case/esac is also useful in one-liners.
- It is generally faster to start a shell than another interpreter (although bash has almost fixed that, so this is not so much of an issue on GNU systems). If you have lots of small scripts, that matters (think init, for example).
- You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
On the other hand, nobody proposes to write something like Zope in sh. Both Shell and higher-level languages have their uses, as have lower-level languages like C or assembly. The good programmer/admin is the one who can use more than one tool productively, and knows when to use which.Programming can be fun again. Film at 11.
And free as in beer:
Advanced Bash-Scripting Guide
Never ascribe to malice that which is adequately explained by incompetence.
Please don't mention NCR! It's been almost 3 years since I quit as a field engineer and I still have nightmares...
What exactly is more powerful and less fragile about Python in comparison to a sh script?
If you are serious, you need to freshen up your computing skills a little bit. Shell scripts tend to fail in unpredictable ways, often with no clue what went wrong. Python script raises an exception that immediately tells where the problem is.
Programming languages are for writing programs to do things, sh scripts are for tying things together in an automated way.
You don't realize that things have changed from the time sh was developed. Better languages for the job exist now. Some of us can recognize superior technology - others repeat obsolete tautologies like mantras, with zero understanding of technological realities.
Python is a nightmare to do nearly anything complex with for me.
I'm not sure what that sentence means.
It requires way too many dependencies, is less reliable than good old "${SHELL}", and typically requires more overhead from my CPU and memory.
I'm not sure what kind of boxen you work with, but they certainly sound pretty broken and underpowered. Buy some p5, they should go for pretty low prices these days and have enough power to run these "heavy" tools.
Happy New Year, troll.
I think this underlines your mentality. Mod down and flame, instead of sticking to technical issues. The technical points you present sound pretty childish to me, and showcase a profound lack of understanding of the issues involved w/ complex systems. You should really catch up w/ the times, or be buried w/ the obsolete Unix boxen you currently maintain.
BTW, if I notice something postworthy I post w/ my real name and skip moderation. Disagreeing with someone doesn't mean it's a troll.
Save your wrists today - switch to Dvorak
Here's a clue: there's more to *nix than Linux.
For two, believe it or not, outside of Linux, Python doesn't necessarily come with a Unix system by default, and no, where I work (a huge financial company), they won't let you compile an external package on a production host. Nor does Python come with the default OpenBSD installation that I run on an old Pentium which I happily use as a router/firewall at home. Granted, it's not a big deal to install Python on OpenBSD, but really, it takes more time and probably effort than piping find to xargs, and that's about the most advanced "program" that I ever write on that OpenBSD machine.
To summarize, I believe that these two reasons (less verbose and always available) make shell a very viable scripting tool even today, in the presence of Python and Perl. And no, a shell script is not necessarily a mess when written by a good developer, just as Python code is not necessarily all clean and readable when written by a moron.
My only problem with Microsoft is the severity of bugs in their software.
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