Preface
“It fills my head with ideas, only I don't really know what they are.”
—Alice in Through the Looking-Glass and What Alice Found There
Perlness
In the world of languages, the country of Perl is the great melting pot which welcomes all cultures, religions, and beliefs. “Give me your tired, your poorly-supported programmers, your huddled masses yearning to be free of artificial limitations,” says Perl, and those who land on its shores find an environment where they are no longer hampered by a language designer's whimsical notions of elegant semantics and stifling syntactical purity.
Perl's universal availability and ease-of-use make it the most democratic programming language. Unlike many other languages, a relative beginner can write useful programs, whereas effective programmers in other languages normally need to spend a lot longer to learn syntax, operators, and functions. A Perl programmer may possess such expertise, or may be a newcomer who modified some example script to perform a new function.
But the newcomer has another problem: lack of debugging skills. Experience forces the canny to develop an innate knack for debugging due to years of accumulated pain. We want to minimize that pain, because we have suffered it. Perl's ease of use allows programmers with little knowledge to create usable, if fragile, code. The amount of time it takes to debug a Perl program can vary dramatically from person to person. Our goal is to help you minimize the development, debugging, and maintenance time you need for your own Perl programs.
Do not take the title of this book to imply we are debugging Perl itself in these pages. What few bugs exist in the Perl interpreter are a matter of minute exotica (or exotic minutiae), rapidly squashed by the fine volunteer crew supporting Perl. A more accurate title would have been Debugging Your Perl Programs, but that felt too pedestrian and loses the “unplugged” pun.
We wrote this book because we wanted you to see the development process at work. Most books on programming contain carefully crafted examples honed through sweaty practice to work perfectly and stand as mute testimonial to the elegant style of the author. They don't show you the ugly, irritating process it took to get the examples into shape; yet those examples did not in fact spring into existence fully formed from the forehead of their creator. Because you will experience this same process when developing your programs, we want to guide you through it and describe various ways around the embarrassment, humiliation, and surprising pitfalls that stand between you and Great Programming.
Within this book, we describe the most common and annoying mistakes a new Perl programmer might make, and then detail the procedures to identify and correct those bugs and any others. You should have some knowledge of Perl; several fine tutorials exist to free us from the onerous responsibility of explaining scalars and arrays and hashes and the like. This preface includes a few references to some of the most useful of these tutorials.
We will not attempt to define or describe a proper programming “style.” Style is as unique as an individual—but a few general rules create a common reference so that we can easily read each other's programs.
Neither is this a “how to program” book. Although we will probe into the mechanics and underpinnings of the general principle of programming at times, it is not our intention to inculcate a complete newcomer with the mindset of the programmer's discipline.
Who Are You?
If you've been programming in Perl anywhere from a week to a year and want to speed up your development cycle, this book is for you. We'll also address some issues related to developing in a team. This book is intended to assist those who have started learning Perl by providing practical advice on development practices.
What This Book Covers
Here's what you'll find in the rest of this book:
Chapter 1: Introduction and a guided tour of the Perl documentation
Chapter 2: Developing the right mindset for programming and developing effectively
Chapter 3: “Gotchas” in Perl: Working your way around some of the tricky things to understand or get right in Perl programming
Chapter 4: Antibugging: How to code defensively
Chapter 5: How to instrument your code
Chapter 6: How to test your Perl programs
Chapter 7: A tour of the perl debugger: our guide to using this built-in tool
Chapter 8: Types of syntax error and how to track down their causes
Chapter 9: Run-time errors
Chapter 10: Semantical errors: When your program appears to work but doesn't do the right thing
Chapter 11: How to improve the performance of a resource-hungry (memory, CPU cycles, and so on) program
Chapter 12: Tips and pitfalls for people coming to Perl from other languages
Chapter 13: Common Gateway Interface (CGI) programming: special tips for debugging this type of Perl program
Chapter 14: Conclusion
Appendix A: Reference for the Perl debugger commands
Appendix B: List of our “Perls of Wisdom”
We will spend a lot of time going through examples of problems and how you might debug them.
Getting Perl
While this isn't a book about how to install or build perl,[1] we owe you at least rudimentary instructions on how to get a perl of your own.
[1] That's not a typo. By convention, big-P Perl refers to the language in the abstract, whereas little-p perl refers to the program that runs Perl programs.
For Windows machines, get the free ActivePerl distribution:
For Macintoshes:
For binary distributions for all other machines:
For the source of perl itself:
Building perl from source on a supported Unix architecture requires just these commands after you download and unpack the right file:
./Configure make make test make install # if the make test succeeds
The Configure step asks you zillions of questions, and most people won't have a clue what many of those questions are talking about; but the default answers Configure recommends are usually correct.
For educational purposes, you may want to build a perl that has debugging enabled. (Here we refer to a perl that lets you use the special -D flag to enable the output of information that tells you what perl is doing with your program. This has nothing to do with Perl's built-in interactive debugger—which we discuss in Chapter 7—all perls have that.) If you want to do that, build perl from the source, and when Configure asks, “Any additional cc flags?” paste in whatever it already shows between brackets as a default and add “ -DDEBUGGING”. See the perlrun POD page (explained later) for more information.
We occasionally refer to modules that are not part of the core Perl distribution but that can be found on the Comprehensive Perl Archive Network (CPAN). For instructions on how to find, download, and install a module from CPAN, see http://www.cpan.org/misc/cpan-faq.html.
Typographical Conventions
We use the following conventions in this book:
Standard text: Times Roman
Author's comments: Arial
Code examples and URLs: Courier
User input: bold Courier
Sometimes our code examples have line breaks where none existed in the original. In places where these line breaks would cause problems or aren't obvious, we've put a backslash () at the end of the line to indicate that the line should be joined with the next one.
 | Occasionally, we want you to know which of us is talking to you, so we have this style of comment to let you know. (This is Ed, by the way.) |
 | Those marginal icons are part of the terrific artwork created by my wife's sister, Ann Palmer, for this book. (This is Peter, by the way.) |
For Further Reference
Visit this book's Web site at http://www.perldebugged.com.
Get introductions to Perl programming from the following (in rough order of usefulness):
• Learning Perl, 2nd ed., by Randal Schwartz and Tom Christiansen (O'Reilly & Associates, 1997)
• Programming Perl, 3rd ed., by Larry Wall Tom Christiansen, and Jon Orwant (O'Reilly & Associates, 2000)
• Perl, the Programmer's Companion, by Nigel Chapman (John Wiley & Sons, 1998)
• Elements of Programming with Perl, by Andrew Johnson (Manning Publications, 1999)
• Effective Perl Programming, by Joseph Hall with Randal Schwartz (Addison-Wesley, 1998)
Perl Versions
In this book, we refer to the latest “stable” version of Perl, which is 5.6.0 as of this writing. The vast majority of what we say works unaltered on older versions of Perl 5, but not Perl 4. If you use any version of Perl older than 5.004_04, you should upgrade; 5.003 had issues such as security problems and memory leaks. You can find out the version number of your perl by passing it the -v flag:
% perl -v
This is perl, v5.6.0 built for i586-linux
Copyright 1987-2000, Larry Wall
[...]
Perl won't execute a script named on the command line if the -v flag is present. A more detailed description of your perl's configuration can be obtained with the -V flag; if you issue a bug report, the facility for doing that automatically includes this information with your report.[2]
[2] Using the perlbug program included with your perl distribution.
A separate development track exists for Perl; you will know if you have one of those versions because the release number either contains an underscore followed by a number of 50 or larger or contains an odd number between two dots. Nothing is guaranteed to work in such a distribution; it's intended for testing. If you find you have one and you didn't want it, the person who downloaded your perl probably visited the wrong FTP link.
It was announced at the fourth annual Perl Conference (Monterey, California, July 2000) that Perl 6 development was beginning in earnest, and backward compatibility need not stand in the way of doing good things. As of press time, discussion continues on new language features.
Acknowledgments
 | I would like to thank David Noble for the original version of the proxylog tool and Ilya Zakharevich for educating me on the intricacies of the Perl debugger. My greatest thanks go to my wife Grace for her love and support through this intensely busy time. |
 | As always, thanks to my grandmother, Mrs. Charles D. Wright Sr., who let me play with computers and read Doc Savage books, and to Mary O'Brien, who originally approached me about this project. |
In addition, we both thank our editor, Mike Hendrickson, and his colleagues, Julie Debaggis and Marcy Barnes, for their tireless support, patience, and understanding while they took a risk on two newcomers to the field and gently ushered us into the fold of authordom. Among the rest of the tireless and often anonymous cast at Addison-Wesley we thank Cathy Comer, Mary Cotillo, Jacquelyn Doucette, John Fuller, Karin Hansen, Katie Noyes, Heather Olszyk, and Heather Peterson.
Our thanks also go to Elaine Ashton for reviews and screenshots, and to Brad Appleton, Sean M. Burke, Joseph Hall, Jarkko Hietaniemi, Michael G. Schwern, and other reviewers for their insightful and helpful comments, which have improved this book immeasurably. Any remaining errors are in no way attributable to them.