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.
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
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!
The one Amazon.com review gave this book 4 stars.
Helevius
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
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Constitutionally Correct
In my mind shell scripting sits at the highest level of process control. You are basically working above all other methods to control your machine with a thin and light interface. In shell scripts, you typically start and stop processes, check for active processes, log information about processes, control the flow of or filter process data. You also work directly with files on the file system by checking for them, moving them, renaming them, deleting them, appending to them, etc. In short, shell scripting is exactly what it says it is...scripting what you would otherwise do by hand at the shell prompt.
Shell scripting usually trumps all other programatic languages in that the engine is so small. That allows it to start up and shutdown really quick, not like the bloated Perls, Pythons, Java's, VBs, etc. A typical shell script engine might use about a Meg or less. Shell scripting is not programming in the strict sense of the word. You are not working in a well structured and cohesive language to be used for a variety of application development. No, shell scripting was made primarily for process and file system management. Making shell scripting work much beyond those means is an art, and not something that should ordinarily be done because other better languages should be used to fulfill broader purposes.
In our Windows environment we use CMD.EXE, or the command shell engine for just about all of our network control scripting. It comes with Windows, and is the only standardized default shell console. The command shell of NT/2k/XP is NOT your fathers BATCH language. Microsoft made some extensive professional changes to the command shell engine starting way back with Windows NT 3.51. The command shell is now very functional and has many Bourne shell syntax features.
Microsoft hasn't promoted the use of the command shell until very recently. This is because early on, they wanted to push system programmers and admins into using their GUI tools and VB scripting languages so that you would have to buy other products. Microsoft really pushed people away from using command shell scripting for the purpose of their own gain. Recently, with the gowing popularity of Linux and Unix again, they are now pushing to get people to use the command shell. They've finally documented most of the many changes they've made to the shell over the years, those changes that were kept in secret to all but the most diehard shell users.
The most popular changes come with the following commands...
CALL, GOTO, EXIT, FOR, and SET.
These commands have been expanded for the development of subroutines, string manipulation, math functions, tokenizing, file system recursion and enumeration. The command processor is fairly powerful in its own right because you don't have to exit very much for externals like FINDSTR, or SED/AWK type executables.
Under NT/2k/XP if you are using the ".BAT" extension for your scripts, or the "COMMAND.COM" processor, then don't. These are now outdated. If you fire up command.com, the the 2k kernel must startup the 16 bit virtual dos machine (VDM). This is S-L-O-W, and the BATCH language is indeed very poor. You should now use the ".CMD" extension for your command shell scripting.
See the following for more command shell (cmd.exe) documentation...
Command Shell Docs
- 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.
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.