|Perl Cookbook: Solutions and Examples for Perl Programmers|
|author||Tom Christiansen and Nathan Torkington|
|publisher||O'Reilly & Associates|
|summary||An indispensable compendium of Perl programming problems with expert solutions and commentary.|
The ScenarioThe first Perl book, "Programming Perl", (Larry Wall and Randal Schwartz, 1990; aka the Red Camel) included 2 chapters, "Common Tasks with Perl" and "Real Perl Programs", that were left out of the second edition of the book ("Programming Perl", by Wall, Tom Christiansen and Schwartz, 1996; aka the Blue Camel). Many people bemoaned the omission of all these Perl-at-work gems and one of the authors, Tom Christiansen, undertook to expand the 2 orphan chapters into a separate book. Two years later, with the help of fellow Perl programmer and Perl FAQ maintainer, Nathan Torkington, Christiansen gave us the "Perl Cookbook" (aka the Ram book).
While no review can even get close to summarizing the wealth of information in this book, its structure is easily described: the organizing metaphor is the cookbook and therefore the bulk of each chapter contains recipes designed to address specific programming problems.
A Code FeastHere's a brief list of other goodies you can find in this book:
- a juicy regex grabbag, that shows how to match HTML links, IP addresses, all-caps words and key=value pairs among many other patterns.
- A full chapter on Database access that in addition to DBI also includes the most extensive discussion of DBM files in Perl literature.
- 40 pages on UNIX processes from the point of view of Perl.
- Examples on how to write demon and non-forking servers in the chapter on sockets and code to create robots, parsing server logs and automating form submission in the chapter on web automation.
- Numerous tips and examples of safe and efficient CGI programming in the chapter devoted to this.
- How to keep your modules separate from the system-wide ones and how to prepare modules you've written for CPAN distro
- Everything you ever wanted to do to dates/time but didn't quite know how .
At times, though, the authors can't keep themselves to just code snippets and
cook a full ready-to-eat meal in the form of a complete program to cap the
solutions presented in a chapter.
At the end of the Pattern Matching chapter, for example, you can find 'tcgrep', Tom Christiansen's cross-platform supergrep that "ignores anything not a plain text file, automatically expands compressed or gzipped files, recurses down directories, searches complete paragraphs or user-defined records . . . and adds underlining or highlighting of the matches". A program called 'hopdelta' caps the "Dates and Times" chapter and shows the time an email message took to reach each destination based on an analysis of its header.
Anatomy of a ChapterAfter an introduction that tries to present the history and general outline of the topic of the chapter come the numbered recipes. Each recipe is divided into 4 parts: a brief statement of the Problem, followed by the code of the Solution and a detailed Discussion with further comments, code examples and pitfalls. The recipe ends with a See Also paragraph that sends the reader to the relevant man pages and further references.
Chapter 7, for instance, deals with File Access. It opens with a 4-page discussion of the basic concepts of file handles and I/O. It then quickly moves into the recipes, which range from the basic (opening a file, covered in depth, output flushing) to the often used and asked about (writing a filter, modifying a file) and ends with a longish complete program that implements lock control over a designated region of a file. Changing a file has 3 sections devoted to it: in-place modification using a temp file, doing it from the command line and the less common in-place modification without a temp file.
(Note: if you've been modelling your file locking on the flock() example on pp.166-7 of the Camel book, make sure you check out recipe 7.11, "Locking a File", to see what you may be doing wrong).
What's Bad?I'd say: nothing. A caveat is in order, though.
Good recipes do not a gourmet cook make. A handy compendium of code snippets like the ones in this book will help solve the problem at hand, but won't help you design better programs. I don't mean to detract from the book's value (after all its purpose is not to teach program structure), just to deflate a little the beginning Perl programmer who uses this book to get unstuck: he's solved the problem at hand and that's great, but he's not necessarily a better programmer for it. The authors are probably aware of this, hence the complete programs at the end of the chapters. I only wish there were more of these.
What's Good?Lucid presentation and clear organization make this book not only useful to refer to, but also pleasant to read through. And the code in it comes not only from experienced authors, but has also been polished by the feedback from scores of Perl gurus, which is a pretty good guarantee of its quality.
Do YOU Need the Ram book?To make it short, let's actually ask: "who doesn't need the Ram book?"
If you're Larry Wall, you probably don't need it . That's it. For the rest of the Perl crowd this book is pretty much an essential companion to the Camel, as both resource and learning tool.
(Note: If you use Perl to teach yourself programming, use the Llama ("Learning Perl," by Randal Schwartz) to get going, but keep the Ram in mind: if you get anywhere with Perl you too will want it).
Buy this book here.
- Dates and Times
- Pattern Matching
- File Access
- File Contents
- References and Records
- Packages, Libraries, and Modules
- Classes, Objects, and Ties
- Database Access
- User Interfaces
- Process Management and Communication
- Internet Services
- CGI Programming
- Web Automation