by Greg DeKoenigsberg
Author: Carl Albing, JP Vossen, and Cameron Newham
Publisher: O’Reilly Media
Publication date: May 2007
One of the reasons I love cookbooks, of all kinds, is because cookbooks have a clarity and simplicity of purpose. Whether it’s a cookbook for code geeks or for food geeks, its raison d’etre is the same: the “cook” has a job to do, and not a lot of time to do it. If a home chef wants to whip up a nice dinner for guests, he don’t want to have to understand the entire history of French cooking; he just wants a simple, well-written recipe for coq au vin. Similarly, if a sysadmin wants to receive an hourly email with a list of zombie processes on the new test server down the hall, she probably wants to hack together a quick bash script, and she doesn’t want to read the collected works of Grady Booch to do it.
Therefore, for me, the best benchmark of a code cookbook is how effectively I can go from the idea, “I need a script to do ‘foo’,” to having a script that does “foo” effectively. It was with this purpose in mind that I set O’Reilly’s new bash cookbook down next to me.
A little background: I’m a lazy Perl guy. I picked up Perl at a wage slave job in the early ’90s–scanning huge documents, running them through OCR, and turning them into SGML files, hours and hours of blinding drudgery–and I became accustomed to using Perl for all kinds of tasks. It was easy, it was flexible, it was powerful, and I didn’t much care about incurring a bit of system overhead, so long as the script did what I wanted it to do and didn’t send the system into swap death. I knew in my heart that learning proper shell scripting was the “right” way to do things, but the syntax of the various shells was always a bit too idiosyncratic for my tastes. And, hey, Perl was everywhere.
A bash cookbook to teach me the error of my ways seemed really exciting.
My first task was to try to figure out some of the weird stuff that my custom build of Planet CCRMA was doing. Particular processes would go zombie on me for no good reason, even when the system was basically idle. I wanted to get a process list for the system every minute, pull the process tree for a particular application and its children, munge the data a bit, and append the timestamped results to a log file. What better excuse to learn bash?
So I picked up the trusty bash cookbook and looked in the index under “fixed-width.” Since
ps uses fixed-width indentations to denote child processes, it seemed like a good place to start. What’s the best way to parse fixed-width data in bash? Ah-hah! “Fixed width data, 273.”
And there it is on page 273. “Problem: You need to read and process data that
is in a fixed-length (also called fixed-width) form.”
“Solution: Use Perl or gawk 2.14 or greater.”
Wait…what? I picked up this book to get over my Perl addiction, and you send me right back to get another fix? Okay, so maybe I chose a bad example.
Moving on to the next example: the classic “rename” problem. As experienced Unix-y CLI users know, the
mv command is incapable of renaming multiple files. It seems like something that should work, but it doesn’t. I wanted to rename a whole bunch of image files I’d pulled from my camera. Just wanted to add a quick “-old” between the filename and the extension. Pretty simple.
So again I picked up the bash cookbook and looked for “rename” in the
index. Voila, page 41. The exact recipe I wanted, in a four line bash script. And not only that, but a discussion about how to change those four lines to do various other things–replacing echo with mv for testing purposes, for example. Good stuff. Just what I wanted.
Yes, yes, there are dozens of other ways I could have done either of these two simple tasks. I know. In fact, bash cookbook introduced me to the “rename” command in our very own util-linux package, which nicely solves the
mv renaming problem. But the point is, I don’t know those solutions, and I don’t have time to look for them, and it’s frequently the case that Googling for something like “bash rename” turns up lots of answers of widely varying quality.
I used bash cookbook for a week. Of the half-dozen times I cracked it open, it helped me more often than it didn’t. Now, I still believe that the old UNIX Power Tools book is still the best book ever written about the UNIX command line, and likely always will be–but bash cookbook has earned its place in my reference book rotation.