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.
he worked on the chapter on name-dropping and brown-nosing
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
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.