Review: "The Linux Command Line"
Off the Beat: Bruce Byfield's Blog
William E. Shotts, Jr.'s The Linux Command Line is really two books in one. In the first two-thirds, Shotts offers one of the better introductions to the Bash shell that I have seen. However, in the last third, the book describes shell scripting, and the tone and pace of the book change so much that you have to wonder why these two sections are between the same covers.
This structure is deliberate. Early in the book, Shotts specifically identifies his audience as power users who have just migrated from another operating system. From this description, you can easily guess how the first two-thirds is meant to prepare readers for the last third.
Unfortunately, though, that is not how The Linux Command Line reads. Rather than the first section preparing for the second, the discrepancy between the two sections is so great that it is hard to review the book as a whole. Instead, it seems more accurate to review the two sections separately.
The First Two Thirds
Shotts states in so many words that the book is meant to be read from the beginning, rather than consulted randomly like an encyclopedia, so he starts as basically as possible. Starting with headings like "What Is the Shell?" and "Navigation," for the first 309 pages, he progresses through such topics as permissions, package management, and compiling source code, adding eight or ten commands to readers' repertoires with each chapter.
The explanations of these topics are not only a general model of clarity, but more detailed than most writing about the command line. For instance, while many writers treat double and single quotes as interchangeable, Shotts specifies their differences with half a dozen examples apiece. He is equally clear about what exactly the environment is -- a topic that, in my experience, newer users only vaguely understand, largely because so few experts ever explain it with more than a passing appositive phrase.
Shotts is the creator of the LinuxCommand.org site, so he is well-equipped to keep this material from its usual dryness. He initiates readers into the mysteries of /dev/null, and offers such practical advice, such as suggesting running ls before rm to see what the consequences of a proposed sequence of options might be, or making the distinctions that, while Linux has no concept of file extensions, many applications do.
Given the complexity of the topic and Shott's own expertise, inevitably, he leaves some things out -- notably the relation between wild cards, globbing, and regular expressions and why you might want to edit text from the command line -- but he makes far fewer omissions than most writers do when talking about such subjects. Generally, Shotts shows a rare sense of when details and distinctions are needed in the first two-thirds of The Linux Command Line.
The Last Third
In another book, the introductory material might be followed by explanations of how you can perform common desktop tasks like downloading photos or ripping a CD from the command line. However, in The Linux Command Line, the introductory material is not an end in itself, but a presentation of what Shotts calls "an arsenal of command line tools" -- and this continuity creates some problems.
Not that there is anything illogical in the transition to shell scripts. Shotts specifically structures his book around the knowledge needed to write scripts, and in theory the organization is as reasonable as any other possible choice.
Nor is the last third entirely void of the expertise and details that make the first two-thirds a standout. For instance, in the first few pages of the material on scripting, Shotts covers such topics as the locations of scripts and formatting that enables ease of maintenance -- topics that programming books are apt to omit. The progression of subject matter from the simple to the complex, and the clarity of individual procedures is as orderly as in the first two-thirds as well.
The trouble is that the last third attempts to handle much more information than the first two-thirds, but in half the space. Where the first two-thirds are leisurely paced, giving readers a chance to absorb the information, the last third moves more quickly.
It has fewer of the details of the earlier section, and fewer explanations of why the material presented matter. Often, it introduces concepts and examples in such quick succession that readers have no time to absorb one key piece of knowledge before moving on to the rest.
In a word, the last third is rushed. It changes the expectations placed upon the reader -- not least of which is the assumption that readers know enough at this point to make their own connections to the contents of the first two-thirds.
While the first section reads as though pitched to complete beginners, the last section reads as though intended for advanced intermediates. As a result, while the discussion of scripting has useful moments, on the whole it is likely to be less useful than the discussion of command line basics.
Two in One
At his best, Shotts displays a genuine talent for explaining complex material. This talent makes The Linux Command Line's failure to cohere especially disappointing, because you can easily imagine how effective it might have been.
I don't know anything about the details of how the book was written. However, I can't help wondering whether Shotts labored so much over the introductory material that he ran out of time to give the scripting section the same attention. Or perhaps Shotts suddenly discovered a length limitation he to keep. Both circumstances are common enough in publishing.
But, whatever happened, I wish that Shotts had at least twice the space he actually had for scripting. Or, better yet, that he had written two separate books instead of cramming the two subjects into one. When Shotts is on top of his game, he is an effective writer on technical subjects, but The Linux Command Line makes him appear to be an inconsistent one -- which, from a look at his online work, is probably not the case.comments powered by Disqus
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?