Unix Hints and Hacks

Doc Technical, writer of the famous Story about Ping review, which I have now seen on Amazon, and on mailing lists, can review books other then allegories. Yes, it's true-and to prove his point, Doc has taken a hard look at Kirk Waingrow's Unix Hints and Hacks, a book for the system administrators, or those who think they want to one of the few, the proud, etc.

Unix Hints and Hacks
author	Kirk Waingrow
pages	479
publisher	Que
rating	6.5/10
reviewer	Doc Technical
ISBN
summary	This is a somewhat flawed book that contains some useful unix information.

Although it's not spelled out in the title, this book is aimed at unix system administrators. To be useful for the linux user, you'll need to be experienced enough to know when specific examples are appropriate for the linux environment.

According to the introduction, the book's examples were tested with five versions of unix, including Linux 2.x. I'm a programmer by profession, but our group maintains 70+ linux servers and workstations, and we spread the sysadmin work around. So I'm always looking for hints on how to keep the machines humming.

The book is divided into ten chapters, four appendices and a glossary. Of the ten chapters, the first eight are on the "hard" unix subjects like File Management, Networking, and Security, while the last two chapters focus on "soft" subjects: "Users" and "System Administration: The Occupation".

The book is on firmer ground with the former than it is with the latter.

Hints and Hacks

The first seven chapters feature a collection of hints/hacks with one or more examples for each. A typical example is Section 6.2, "Copy Files Remotely". The author describes the problem in a brief paragraph ("...there are times when migrating files over from one host to another is necessary"). This is followed by four examples showing different techniques (using rcp, tar/rsh, nfs mount points, and ftp). Finally, the section ends with three brief sections: "Reasons", "Real World Experiences", and "Other Resources".

According to the back cover, the book is aimed at the intermediate to advanced reader (although the introduction rather contradicts this by claiming that it will be useful to beginners as well). I consider myself comfortably within the intermediate to advanced range, and I honestly did find some useful tips in this book. Most subjects are covered by several examples showing alternative approaches, and this is consistent with the unix "toolkit" philosophy. There's always more than one way to flay a feline.

While aimed at intermediate and advanced users, I suspect most of that audience will be familiar with one or more solutions to most of the problems presented in the book. Where the reader will benefit occasionally is the discovery of a third or fourth alternative to a problem.

Some of the example problems had me shaking my head. In a section called "Remove the --- Dashes ---", the author presents the legitimate problem of removing a file that begins with a dash. If you don't believe this can be a problem, run these commands:

touch /tmp/-wow; cd /tmp; rm -wow

The obvious solution to this problem is to append the directory to the file name so that it doesn't start with a dash:

rm /tmp/-wow

The author provides this solution, along with three alternatives, but the last one raised more questions for me than it answered. The author's last example suggests "rm -r directory". Remove the entire directory. In the author's defence, he does provide numerous warnings in this example, and says it "should be used only as a last resort." But he never did explain why this method would be needed. Under what circumstances would the other methods not work?

There are some factual problems in the book, as in the appendix on "Basic Scripting Concepts" where a section titled "Recursive Scripts" has nothing to do with recursion.

In the "Real World Experience" subsection of the section "Redirecting Output to Null", the author recounts how he once crashed a database application by deleting its log files with rm, and how he quickly learned to redirect /dev/null to the log files to zero them out ("cat /dev/null > logfile"). But he doesn't take the extra step of explaining why rm'ing an open log file might cause an application to crash. Understanding why something happened in the first place is as important as knowing how to fix it.

What's Left Out

This book looks at solutions to specific problems, but never really attempts to teach what I'd call the hacking mentality.

In a section called "Find the Disk Hog", Waingrow shows how to use the du, sort, and head commands to find the top ten disk users like this:

du -s | sort -rn | head -10

He explains how these commands work, and he uses similar command-line examples throughout the book. This is great. Stringing together existing unix commands using pipes and filters is one of the biggest strengths of the operating system. But he never covers these meta-topics, except for a brief mention of pipes in the introduction.

Readers at a beginning level would benefit from an overview of pipes and filters, as well as such essential programs as cut, grep, egrep, head, tail, sort, wc, and tr. Many of these programs are used in examples, and some are explained in context, but a "concepts" chapter would have broadened the book's usefulness.

Perhaps the author assumes that everyone already knows these things, but I suspect many unix and linux administrators have never been explicitly taught them.

The Soft Chapters

The last two chapters of the book, "Users" and "System Administration: The Occupation", are aimed at professional sysadmins. These were, for me, the least useful, but I only perform sysadmin work as an adjunct to my programming.

There are sections on topics like "The Six Types of Users", "Public Relations", and "Preparing for an Interview". These are soft subjects not related to unix per se, but they may be useful to administrators.

Some of the advice in these last two chapters will be of most benefit to those just starting out in the field. Much of the advice seemed (to me) to be common sense. In the section "Being Interviewed", Waingrow suggests "Don't ever cut the interviewer off in the middle of a sentence", and "Don't lie", and "Don't belittle, debate, disagree, or tell interviewers that they are wrong". Geez, that really screws up my interviewing strategy.

Structural Problems

For me, the book suffered from several irritating structural and organizational problems. The first eight chapters are each divided into roughly a dozen sections. For example, chapter 5, "Account Management", is divided into 16 sections, starting with 5.1, "User Account Names", and running through section 5.16, "Nulling the Root Password Without vi". This is fine. But then each section is broken down again into subsections. How many? Exactly one. It may seem like a minor aesthetic point, but it makes the pages harder to scan visually, and it makes the Table of Contents much harder to read.

Another annoying point is that the book is typeset so that there is less space between the period (.) and the start of a new sentence than there is between individual words. Sentences sometimes seem to crash into one another. Again, a minor point, not the author's fault, but these things add up.

And I have more fundamental problems with the way the book is organized. Each chapter section tackles a single subject, and many of these sections make their intent quite clear: "Dealing with Unwanted Daemons", or "Monitoring at Boot Time". But other section headings are more ambiguous: "Clear and Lock" and "File Collecting" might have been better named as "Clearing and Locking the Screen" and "Finding Suspicious Files".

As a benchmark, I looked at the organization of the recent "Perl Cookbook" by Christiansen and Torkington. This book is a similar collection of brief solutions to specific problems. The Perl Cookbook avoids many of the problems that harm "Unix Hints and Hacks". Section headings are descriptive and unambiquous, and they use a consistent verb tense. The layout is clean and readable. The publishers could take some lessons from O'Reilly.

Editing

In places, a little editing would have helped the prose. Here's an example from page 144:

"When a program is sent a QUIT signal, it writes out what was in memory at the time the signal was sent to disk."

I'm pretty sure the signal was not not sent to disk, but this dangling modifier could easily have been recast:

"When a program is sent a QUIT signal, it writes to disk what was in memory at the time the signal was sent."

Writers are going to make mistakes like this, it's the editor's job to find them. This editor too often didn't.

Bottom Line

The weaknesses of this book get in the way of its strengths. Tighter writing, tighter editing, and a tighter focus would help this book enormously.

A focus on the hard-core unix topics presented in the first seven chapters, with some additional material on the unix toolkit mentality, could be the basis for a good second edition of this book.

I would recommend skimming through this book at your local bookstore. If, after a few minutes, you find more than two or three examples that are useful, you'll likely benefit from this book.

Else, pick it up at Amazon.