Unix Shell Programming, Third Edition

honestpuck writes "Back when dinosaurs roamed the earth and NCR made Unix computers I first started to program for a living. Back then when someone said 'script' they meant a shell script, generally for a Bourne shell." Even if the definition of "scripting" has grown somewhat, honestpuck argues, the old meaning still has merit and use. Read on for his review of the latest edition of Unix Shell Programming. Unix Shell Programming, Third Edition author Stephen G. Kochan and Patrick Wood pages 406 publisher SAMS rating 8 - Well written, good topic coverage, some small flaws reviewer Tony Williams ISBN 0672324903 summary Good introduction to shell programming and using the shell

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.

Comments

Shell scripting is a Lost Art

[Saeed al-Sahaf]

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).

This raises an interesting question...

[Anonymous Coward]

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?

Shell scripts

[RealProgrammer]

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.

My mantra

[jjgm]

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