Programming Perl: Unmatched Power for Text Processing and Scripting

by Tom Christiansen, brian d foy, Larry Wall, Jon Orwant

Overview

Adopted as the undisputed Perl bible soon after the first edition appeared in 1991, Programming Perl is still the go-to guide for this highly practical language. Perl began life as a super-fueled text processing utility, but quickly evolved into a general purpose programming language that’s helped hundreds of thousands of programmers, system administrators, and enthusiasts, like you, get your job done.

In this much-anticipated update to "the Camel," three renowned Perl authors cover the language up to its current version, Perl 5.14, with a preview of features in the upcoming 5.16. In a world where Unicode is increasingly essential for text processing, Perl offers the best and least painful support of any major language, smoothly integrating Unicode everywhere—including in Perl’s most popular feature: regular expressions.

Important features covered by this update include:

• New keywords and syntax
• I/O layers and encodings
• New backslash escapes
• Unicode 6.0
• Unicode grapheme clusters and properties
• Named captures in regexes
• Recursive and grammatical patterns
• Expanded coverage of CPAN
• Current best practices

Product Details

ISBN-13:	9780596004927
Publisher:	O'Reilly Media, Incorporated
Publication date:	03/05/2012
Edition description:	Fourth Edition
Pages:	1174
Product dimensions:	7.00(w) x 9.20(h) x 2.30(d)

About the Author

Tom Christiansen is a freelance consultant specializing in Perl training and writing. After working for several years for TSR Hobbies (of Dungeons and Dragons fame), he set off for college where he spent a year in Spain and five in America, dabbling in music, linguistics, programming, and some half-dozen different spoken languages. Tom finally escaped UW-Madison with undergraduate degrees in Spanish and computer science and a graduate degree in computer science. He then spent five years at Convex as a jack-of-all-trades working on everything from system administration to utility and kernel development, with customer support and training thrown in for good measure. Tom also served two terms on the USENIX Association Board of directors. With over thirty years' experience in Unix systems programming, Tom presents seminars internationally. Living in the foothills above Boulder, Colorado, Tom takes summers off for hiking, hacking, birding, music making, and gaming.

brian d foy is a prolific Perl trainer and writer, and runs The Perl Review to help people use and understand Perl through educational, consulting, code review, and more. He's a frequent speaker at Perl conferences. He's the coauthor of Learning Perl, Intermediate Perl, and Effective Perl Programming, and the author of Mastering Perl. He was an instructor and author for Stonehenge Consulting Services from 1998 to 2009, a Perl user since he was a physics graduate student, and a die-hard Mac user since he first owned a computer. He founded the first Perl user group, the New York Perl Mongers, as well as the Perl advocacy nonprofit Perl Mongers, Inc., which helped form more than 200 Perl user groups across the globe. He maintains the perlfaq portions of the core Perl documentation, several modules on CPAN, and some standalone scripts.

Larry Wall originally created Perl while a programmer at Unisys. He now works full time guiding the future development of the language. Larry is known for his idiosyncratic and thought-provoking approach to programming, as well as for his groundbreaking contributions to the culture of free software programming.

Jon Orwant founded The Perl Journal and received the White Camel lifetime achievement award for contributions to Perl in 2004. He's Engineering Manager at Google, where he leads Patent Search, visualizations, and digital humanities teams. For most of his tenure at Google, Jon worked on Book Search, and he developed the widely used Google Books Ngram Viewer. Prior to Google, he was
CTO of O'Reilly, Director of Research at France Telecom, and a Lecturer at MIT. Orwant received his doctorate from MIT's Electronic Publishing Group in 1999.

Read an Excerpt

Chapter 5: Packages, Modules, and Object Classes

...Within the class package, methods will typically deal with the reference as an ordinary (unblessed) reference to a thingy. Outside the class package, the reference should generally be treated as an opaque value that may only be accessed through the class's methods. (Mutually consenting classes may of course do whatever they like with each other, but even that doesn't necessarily make it right.)

A constructor may re-bless a referenced object currently belonging to another class, but then the new class is responsible for all cleanup later. The previous blessing is forgotten, as an object may only belong to one class at a time. (Although of course it's free to inherit methods from many classes.)

A clarification: Perl objects are blessed. References are not. Thingies know which package they belong to. References do not. The bless operator simply uses the reference in order to find the thingy. Consider the following example:

$a = {}; # generate reference to hash
$b = $a; # reference assignment (shallow)
bless $b, Mountain;
bless $a, Fourteener;
print "\$b is a ", ref ($b), "\n";

This reports $b as being a member of class Fourteener, not a member of class Mountain, because the second blessing operates on the underlying thingy that $a refers to, not on the reference itself. Thus is the first blessing forgotten.

A Class Is Simply a Package

Perl doesn't provide any special syntax for class definitions. You just use a package as a class by putting method definitions into the class.

Within each package a special array called @ISA tells Perlwhere else to look for a method if it can't find the method in that package. This is how Perl implements inheritance. Each element of the @ISA array is just the name of another package that happens to be used as a class. The packages are recursively searched (depth first) for missing methods, in the order that packages are mentioned in @ISA. This means that if you have two different packages (say, Mom and Dad) in a class's @ISA, Perl would first look for missing methods in Mom and all of her ancestor classes before going on to search through Dad and his ancestors. Classes accessible through @ISA are known as bare classes of the current class, which is itself called the derived class.

If a missing method is found in one of the base classes, Perl internally caches that location in the current class for efficiency, so the next time it has to find the method, it doesn't have to look so far. Changing @ISA or defining new subroutines invalidates this cache and causes Perl to do the lookup again.

If a method isn't found but an AUTOLOAD routine is found, then that routine is called on behalf of the missing method, with that package's $AUTOLOAD variable set to the fully qualified method name.

If neither a method nor an AUTOLOAD routine is found in @ISA, then one last, desperate try is made for the method (or an AUTOLOAD routine) in the special predefined class called UNIVERSAL. This package does not initially contain any definitions (although see CPAN for some), but you may place your "last-ditch" methods there. Think of it as a global base class from which all other classes implicitly derive.

If that method still doesn't work, Perl finally gives up and complains by raising an exception.

Perl classes do only method inheritance. Data inheritance is left up to the class itself. By and large, this is not a problem in Perl, because most classes model the attributes of their object using an anonymous hash. All the object's data fields (termed "instance variables" in some languages) are contained within this anonymous hash instead of being part of the language itself. This hash serves as its own little namespace to be carved up by the various classes that might want to do something with the object. For example, if you want an object called $user_info to have a data field named age, you can simply access $user_info->{age}. No declarations are necessary. See the section on "Instance Variables" under "Some Hints About Object Design" later in this chapter.

A Method Is Simply a Subroutine

Perl doesn't provide any special syntax for method definition. (It does provide a little syntax for method invocation, though. More on that later.) A method expects its first argument to indicate the object or package it is being invoked on.

Class methods

a class method expects a class (package) name as its first argument. (The class name isn't blessed; it's just a string.) These methods provide functionality for the class as a whole, not for any individual object instance belonging to the class. Constructors are typically written as class methods, Many class methods simply ignore their first argument, since they already know what package they're in, and don't care what package they were invoked via. (These aren't necessarily the same, since class methods follow the inheritance tree just like ordinary instance methods.)...

Table of Contents

• Preface
• Part I: Overview
  • Chapter 1: An Overview of Perl
• Part II: The Gory Details
  • Chapter 2: Bits and Pieces
  • Chapter 3: Unary and Binary Operators
  • Chapter 4: Statements and Declarations
  • Chapter 5: Pattern Matching
  • Chapter 6: Unicode
  • Chapter 7: Subroutines
  • Chapter 8: References
  • Chapter 9: Data Structures
  • Chapter 10: Packages
  • Chapter 11: Modules
  • Chapter 12: Objects
  • Chapter 13: Overloading
  • Chapter 14: Tied Variables
• Part III: Perl as Technology
  • Chapter 15: Interprocess Communication
  • Chapter 16: Compiling
  • Chapter 17: The Command-Line Interface
  • Chapter 18: The Perl Debugger
  • Chapter 19: CPAN
• Part IV: Perl as Culture
  • Chapter 20: Security
  • Chapter 21: Common Practices
  • Chapter 22: Portable Perl
  • Chapter 23: Plain Old Documentation
  • Chapter 24: Perl Culture
• Part V: Reference Material
  • Chapter 25: Special Names
  • Chapter 26: Formats
  • Chapter 27: Functions
  • Chapter 28: The Standard Perl Library
  • Chapter 29: Pragmatic Modules
• Index of Perl Modules in This Book
• Colophon

Preface

Perl is a language for getting your job done.

Of course, if your job is programming, you can get your job done with any "complete" computer language, theoretically speaking. But we know from experience that computer languages differ not so much in what they make possible, but in what they make easy. At one extreme, the so-called "fourth generation languages" make it easy to do some things, but nearly impossible to do other things. At the other extreme, certain well known, "industrial-strength" languages make it equally difficult to do almost everything.

Perl is different. In a nutshell, Perl is designed to make the easy jobs easy, without making the hard jobs impossible.

And what are these "easy jobs" that ought to be easy? The ones you do every day, of course. You want a language that makes it easy to manipulate numbers and text, files and directories, computers and networks, and especially programs. It should be easy to run external programs and scan their output for interesting tidbits. It should be easy to send those same tidbits off to other programs that can do special things with them. It should be easy to develop, modify, and debug your own programs too. And, of course, it should be easy to compile and run your programs, and do it portably, on any modern operating system.

Perl does all that, and a whole lot more.

Initially designed as a glue language for the UNIX operating system (or any of its myriad variants), Perl also runs on numerous other systems, including MS-DOS, VMS, OS/2, Plan 9, Macintosh, and any variety of Windows you care to mention. It is one of the most portable programming languages available today. To program Cportably, you have to put in all those strange #ifdef markings for different operating systems. And to program a shell portably, you have to remember the syntax for each operating system's version of each command, and somehow find the least common denominator that (you hope) works everywhere. Perl happily avoids both of these problems, while retaining many of the benefits of both C and shell programming, with some additional magic of its own. Much of the explosive growth of Perl has been fueled by the hankerings of former UNIX programmers who wanted to take along with them as much of the "old country" as they could. For them, Perl is the portable distillation of UNIX culture, an oasis in the wilderness of "can't get there from here". On the other hand, it works in the other direction, too: Web programmers are often delighted to discover that they can take their scripts from a Windows machine and run them unchanged on their UNIX servers.

Although Perl is especially popular with systems programmers and Web developers, it also appeals to a much broader audience. The hitherto well-kept secret is now out: Perl is no longer just for text processing. It has grown into a sophisticated, general-purpose programming language with a rich software development environment complete with debuggers, profilers, cross-referencers, compilers, interpreters, libraries, syntax- directed editors, and all the rest of the trappings of a "real" programming language. (But don't let that scare you: nothing requires you to go tinkering under the hood.) Perl is being used daily in every imaginable field, from aerospace engineering to molecular biology, from computer-assisted design/computer-assisted manufacturing (CAD/CAM) to document processing, from database manipulation to client-server network management. Perl is used by people who are desperate to analyze or convert lots of data quickly, whether you're talking DNA sequences, Web pages, or pork belly futures. Indeed, one of the jokes in the Perl community is that the next big stock market crash will probably be triggered by a bug in a Perl script. (On the brighter side, any unemployed stock analysts will still have a marketable skill, so to speak.)

There are many reasons for the success of Perl. It certainly helps that Perl is freely available, and freely redistributable. But that's not enough to explain the Perl phenomenon, since many freeware packages fail to thrive. Perl is not just free; it's also fun. People feel like they can be creative in Perl, because they have freedom of expression: they get to choose what to optimize for, whether that's computer speed or programmer speed, verbosity or conciseness, readability or maintainability or reusability or portability or learnability or teachability. You can even optimize for obscurity, if you're entering an Obfuscated Perl contest.

Perl can give you all these degrees of freedom because it's essentially a language with a split personality. It's both a very simple language and a very rich language. It has taken good ideas from nearly everywhere, and installed them into an easy-to-use mental framework. To those who merely like it, Perl is the Practical Extraction and Report Language. To those who love it, Perl is the Pathologically Eclectic Rubbish Lister. And to the minimalists in the crowd, Perl seems like a pointless exercise in redundancy. But that's okay. The world needs a few reductionists (mainly as physicists). Reductionists like to take things apart. The rest of us are just trying to get it together.

Perl is in many ways a simple language. You don't have to know many special incantations to compile a Perl program--you can just execute it like a shell script. The types and structures used by Perl are easy to use and understand. Perl doesn't impose arbitrary limitations on your data--your strings and arrays can grow as large as they like (so long as you have memory), and they're designed to scale well as they grow. Instead of forcing you to learn new syntax and semantics, Perl borrows heavily from other languages you may already be familiar with (such as C, and sed, and awk, and English, and Greek). In fact, just about any programmer can read a well-written piece of Perl code and have some idea of what it does.

Most important, you don't have to know everything there is to know about Perl before you can write useful programs. You can learn Perl "small end first". You can program in Perl Baby-Talk, and we promise not to laugh. Or more precisely, we promise not to laugh any more than we'd giggle at a child's creative way of putting things. Many of the ideas in Perl are borrowed from natural language, and one of the best ideas is that it's okay to use a subset of the language as long as you get your point across. Any level of language proficiency is acceptable in Perl culture. We won't send the language police after you. A Perl script is "correct" if it gets the job done before your boss fires you.

Though simple in many ways, Perl is also a rich language, and there is much to be learned about it. That's the price of making hard things possible. Although it will take some time for you to absorb all that Perl can do, you will be glad that you have access to the extensive capabilities of Perl when the time comes that you need them. We noted above that Perl borrows many capabilities from the shells and C, but Perl also possesses a strict superset of sed and awk capabilities. There are, in fact, translators supplied with Perl to turn your old sed and awk scripts into Perl scripts, so you can see how the features you may already be familiar with correspond to those of Perl.

Because of that heritage, Perl was a rich language even when it was "just" a data- reduction language, designed for navigating files, scanning large amounts of text, creating and obtaining dynamic data, and printing easily formatted reports based on that data. But somewhere along the line, Perl started to blossom. It also became a language for file system manipulation, process management, database administration, client-server programming, secure programming, Web-based information management, and even for object-oriented and functional programming. These capabilities were not just slapped onto the side of Perl--each new capability works synergistically with the others, because Perl was designed to be a glue language from the start.

But Perl can glue together more than its own features. Perl is designed to be modularly extensible. Perl allows you to rapidly design, program, debug, and deploy applications, but it also allows you to easily extend the functionality of these applications as the need arises. You can embed Perl in other languages, and you can embed other languages in Perl. Through the module importation mechanism, you can use these external definitions as if they were built-in features of Perl. Object-oriented external libraries retain their object-orientedness in Perl.

Perl helps you in other ways too. Unlike a strictly interpreted language such as the shell, which compiles and executes a script one command at a time, Perl first compiles your whole program quickly into an intermediate format. Like any other compiler, it performs various optimizations, and gives you instant feedback on everything from syntax and semantic errors to library binding mishaps. Once Perl's compiler frontend is happy with your program, it passes off the intermediate code to the interpreter to execute (or optionally to any of several modular back ends that can emit C or bytecode.) This all sounds complicated, but the compiler and interpreter are quite efficient, and most of us find that the typical compile-run-fix cycle is measured in mere seconds. Together with Perl's many fail-soft characteristics, this quick turnaround capability makes Perl a language in which you really can do rapid prototyping. Then later, as your program matures, you can tighten the screws on yourself, and make yourself program with less flair but more discipline. Perl helps you with that too, if you ask nicely.

Perl also helps you to write programs more securely. While running in privileged mode, you can temporarily switch your identity to something innocuous before accessing system resources. Perl also guards against accidental security errors through a data tracing mechanism that automatically determines which data was derived from insecure sources and prevents dangerous operations before they can happen. Finally, Perl lets you set up specially protected compartments in which you can safely execute Perl code of dubious lineage, masking out dangerous operations. System administrators and CGI programmers will particularly welcome these features.

But, paradoxically, the way in which Perl helps you the most has almost nothing to do with Perl, and everything to do with the people who use Perl. Perl folks are, frankly, some of the most helpful folks on earth. If there's a religious quality to the Perl movement, then this is at the heart of it. Larry wanted the Perl community to function like a little bit of heaven, and he seems to have gotten his wish, so far. Please do your part to keep it that way.

Whether you are reaming Perl because you want to save the world, or just because you are curious, or because your boss told you to, this handbook will lead you through both the basics and the intricacies. And although we don't intend to teach you how to program, the perceptive reader will pick up some of the art, and a little of the science, of programming. We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris. Along the way, we hope you find the book mildly amusing in some spots (and wildly amusing in others). And if none of this is enough to keep you awake, just keep reminding yourself that learning Perl will increase the value of your resume. So keep reading.

The Rest of This Book

Here's how the book is laid out:

Chapter 1, An Overview of Perl. Getting started is always hard to do. This chapter presents the fundamental ideas of Perl in an informal, curl-up-in-your-favoritechair fashion. Not a full tutorial, it merely offers a quick jump-start, which may not serve everyone's need. Learning Perl (discussed in the next section) offers a more complete, carefully paced introduction to the language.

Chapter 2, The Gory Details. This chapter consists of an in-depth, no-holds-barred discussion of the guts of the language, from data types, variables, and objects to functions, subroutines, and modules, as well as special variables, control flow, and regular expressions. You'll gain a good sense of how the language works.

Chapter 3, Functions. Here you'll find an authoritative, reference-style description of Perl's built-in functions. The explanations cover function syntax, arguments, and general use.

Chapter 4, References and Nested Data Structures. References in Perl are analogous to pointers in C. This chapter tells you how to create references, how to get at the data they refer to, and how to build complex, nested data structures by using references. A tutorial and extensive examples guide you through the subtleties of the topic.

Chapter 5, Packages, Modules, and Object Classes. Packages give you a tool for namespace management, and library modules enable you to write reusable code. Together, packages and modules provide a basis for Perl's object-oriented facilities. In addition to explaining these matters, this chapter offers a brief refresher on object-oriented programming, illustrates how to treat built-in variables as objects, and provides some hints for good object-oriented design using Perl.

Chapter 6, Social Engineering. This chapter presents how Perl tries to cooperate with everything and everyone in the whole wide world, up to a point.

Chapter 7, The Standard Perl Library. This reference chapter describes all the library modules that come with the standard Perl distribution. These modules greatly extend the range of the language. Interfaces to standard database packages, tools for managing terminal input, mechanisms for loading code on the fly at run-time, mathematical packages, safe programming aids, and much else--it is well worth your time to browse through the brief listing of modules at the beginning of this chapter.

Chapter 8, Other Oddments. Leftovers worthy of a main meal: the Perl debugger, efficiency considerations, common mistakes, programming style, and a few historical and postmodernist notes.

Chapter 9, Diagnostic Messages. Special communications from Perl to you at particularly difficult moments--sometimes helpful, occasionally snide, and too often ignored. But never irrelevant.

Glossary. The words and definitions you'll find here aren't exactly what you'd expect in a normal glossary, but Perl is not really a normal language (nor are the authors of this book really normal authors, or normally real authors).

Additional Resources
Perl Manpages

The online manpages for Perl have been divided into separate sections so you can easily find what you are looking for without wading through hundreds of pages of text. Since the top-level manpage is simply called perl, the UNIX command "man perl" should take you to it¹. That page in turn directs you to more specific pages. For example, "man perlre" will display the manpage for Perl's regular expressions. The peridoc command may work when the man(1) command won't, especially on module documentation that your system administrator may not have felt comfortable installing with the ordinary manpages. On the other hand, your system administrator may have installed the Perl documentation in hypertext markup language (HTML) format.

Usenet Newsgroups

The Perl newsgroups are a great, if sometimes cluttered, source of information about Perl. comp.lang.perl.announce is a moderated, low-traffic newsgroup for Perl-related announcements. These often deal with new version releases, bug fixes, new extensions and modules, and Frequently Asked Questions (FAQs).

The high-traffic comp.lang.perl.misc group discusses everything from technical issues to Perl philosophy to Perl games and Perl poetry. Like Perl itself, comp.lang.perl.misc is meant to be useful, and no question is too silly to ask.²

The comp.lang.perl.tk group discusses how to use the popular Tk toolkit from Perl. The comp.lang.perl.modules group is about the development and use of Perl modules, which are the best way to get reusable code. There may be other comp.lang.perl.whatever newsgroups by the time you read this; look around.

One other newsgroup you might want to check out, at least if you're doing CGI programming on the Web, is comp.infosystems.www.authoring.cgi. While it isn't strictly speaking a Perl group, most of the programs discussed there are written in Perl. It's the right place to go for Web-related Perl issues.

The Perl Homepage

If you have access to the World Wide Web, visit the Perl homepage at http://www.perl.com/perl/. It tells what's new in the Perl world, and contains source code and ports, documentation, third-party modules, the Perl bugs database, mailing list information, and more. This site also provides the CPAN multiplexer, described later.

Also check out http://www.perl.org/, which is the homepage of the Perl Institute, a non- profit organization dedicated to saving the world through serving the Perl community.

Frequently Asked Questions List

The Perl Frequently Asked Questions (FAQ) is a collection of questions and answers that often show up on comp.lang.perl.misc. In many respects it is a companion to the available books, explaining concepts that people may not have understood and maintaining up-to-date information about such things as the latest release level and the best place to get the Perl source.

There is also a metaFAQ, which answers supercommon questions. It has pointers to the current Perl distribution, various non-UNIX ports, and the full FAQ. There may be other FAQs you will find useful--for example, FAQs about non-UNIX ports, Web programming, or perltk.

Another FAQish sort of posting is the Perl Modules List, which keeps track of all the various existing and proposed modules that various folks have worked on, or will work on someday real soon now. Included are the email addresses of people to bug, and much free advice on module design. A must-read for people who don't want to reinvent either the buggy whip or the wheel.

The FAQs are periodically posted to comp.lang.perl.announce, and can also be found on the web at http://www.perl.com/perl/faq.

Bug Reports

In the unlikely event that you should encounter a bug that's in Perl proper and not just in your own program, you should try to reduce it to a minimal test case and then report it with the perlbug program that comes with Perl.

The Perl Distribution

Perl is distributed under either of two licenses (your choice). The first is the standard GNU Copyleft, which means briefly that if you can execute Perl on your system, you should have access to the full source of Perl for no additional charge. Alternately, Perl may also be distributed under the Artistic License, which some people find less threatening than the Copyleft (especially lawyers).

Within the Perl distribution, you will find some example programs in the eg/ directory. You may also find other tidbits. Poke around in there on some rainy afternoon. Study the Perl source (if you're a C hacker with a masochistic streak). kook at the test suite. See how Configure determines whether you have the mkdir(2) system call. Figure out how Perl does dynamic loading of C modules. Or whatever else suits your fancy.

Other Books

Learning Perl by Randal Schwartz (published by O'Reilly & Associates) is a companion to Programming Perl. It is more of a tutorial, whereas this book is more of a reference. If the tutorial section of Programming Perl is too short or assumes too much about your background, try Learning Perl for a kinder, gentler introduction to the language.

The AWK Programming Language, by Aho, Kernighan, and Weinberger (published by Addison-Wesley), and sed & awk, by Dale Dougherty (published by O'Reilly & Associates), provide an essential background in such things as associative arrays, regular expressions, and the general worldview that gave rise to Perl. They also contain many examples that can be translated into Perl by the awk-to-perl translator a2p or by the sed- to-perl translator s2p. These translators won't produce idiomatic Perl, of course, but if you can't figure out how to imitate one of those examples in Perl, the translator output will give you a good place to start.

We also recommend Johan Vromans's convenient and thorough quick reference booklet, called Perl 5 Desktop Reference, published coincidentally by O'Reilly & Associates.

How to Get Perl

The main distribution point for Perl is the Comprehensive Perl Archive Network, or CPAN. This archive contains not only the source code, but also just about everything you could ever want that's Perl-related. CPAN is mirrored by dozens of sites all over the world, as well as a few down under. The main site is ftp funet.fi (128.214.248.6). You can find a more local CPAN site by getting the file /pub/languages/perl/CPAN/MIRRORS from ftp.funet.fi. Or you can use your Web browser to access the CPAN multiplex service at www.perl.com. Whenever you ask this Web server for a file starting with /CPAN/, it connects you to a CPAN site, which it chooses by looking at your domain name. Here are some popular universal resource locators (URLs) out of CPAN:

http://www.perl.com/CPAN/
http://www.perl.com/CPAN/README.html
http://www.perl.com/CPAN/modules/
http://www.perl.com/CPAN/ports/
http://www.perl.com/CPAN/src/latest.tar.gz

The CPAN multiplex service tries to connect you to a local, fast machine on a large bandwidth hub. This doesn't always work, however, because domain names may not reflect network connections. For example, you might have a hostname ending in .se but you may actually be better connected to North America than to Sweden. If so, you can use the following URL to choose your own site:

http://www.perl.com/CPAN

Note the absence of a slash at the end of the URL. When you omit the trailing slash, the CPAN multiplexer presents a menu of CPAN mirrors from which you can select a site. It will remember your choice next time.

The following machines should have the Perl source code plus a copy of the CPAN mirror list--both available for anonymous FTP. (Try to use the machine names rather than the numbers, since the numbers may change.)

ftp.perl.com 199.45.129.30
ftp.cs.Colorado.edu 131.211.80.17
ftp.cise.ufl.edu 128.227.162.34
ftp.funet.fi 128.214.248.6
fqp.cs.rnu.nl 131.211.80.17

The location of the top directory of the CPAN mirror differs on these machines, so look around once you get there. It's often something like /pub/perl/CPAN

Where the Files Are

Under the main CPAN directory, you'll see at least the following subdirectories:

• authors. This directory contains numerous subdirectories, one for each contributor of software. For example, if you wanted to find Lincoln Stein's great CGI module, and you knew for a fact that he wrote it, you could look in authors/Lincoln_Stein. If you didn't know he wrote it, you could look in the modules directory explained below.

• doc. A directory containing all manner of Perl documentation. This includes all official documentation (manpages) in several formats (such as ASCII text, HTML, PostScript, and Perl's native POD format), plus the FAQs and interesting supplementary documents.

• modules. This directory contains unbundled modules written in C, Perl, or both. Extensions allow you to emulate or access the functionality of other software, such as Tk graphical facilities, the UNLX curses library, and math libraries. They also give you a way to interact with databases (Oracle, Sybase, etc.), and to manage HTML files and CGI scripts.

• ports. This directory contains the source code and/or binaries for Perl ports to operating systems not directly supported in the standard distribution. These ports are the individual efforts of their respective authors, and may not all function precisely as described in this book. For example, none of the MSDOS ports implement the fork function, for some reason.

• scripts. A collection of diverse scripts from all over the world. If you need to find out how to do something, or if you just want to see how other people write programs, check this out. The subdirectory nutshell contains the examples from this book. (You can also find these sources at the O'Reilly & Associates ftp.ora.com site, in /pub/examples/nutshell/programming_perl/.)

• src. Within this directory you will find the source for the standard Perl distribution. The current production release is always in the file that is called src/latest.tar.gz,³ which as of this writing is a symbolic link to the file src/5.0/perl5.003.tar.gz, but will likely point to a higher version number by the time you read this. This very large file contains full source and documentation for Perl. Configuration and installation should be relatively straightforward on UNLX and UNIX-like systems, as well as VMS and OS/2.
  Using Anonymous FTP
  

  In the event you've never used anonymous FTP, here is a quick primer in the form of a sample session with comments. Text in bold typewriter font is what you should type; comments are in italics. The % represents your prompt, and should not be typed.

  % ftp ftp.CPAN.org (ftp.CPAN.org is not a real site)
  Connected to ftp.CPAN.org.
  220 CPAN FTP server (Version wu-2.4(1) Fri Dec 1 00:00:00 EST 1995) ready.
  Name (ftp.CPAN.org:CPAN): anonymous
  331 Guest login ok, send your "complete" e-mail address as password.
  Password: [e-mail] (Use your user name and host here.)
  230 Guest login ok, access restrictions apply.
  ftp> cd pub/perl/CPAN/src
  250 CWD command successful.
  ftp> binary (You must specify binary transfer for compressed files.)
  200 Type set to I.
  ftp> get latest.tar.gz
  200 PORT command successful.
  150 Opening BINARY mode data connection for FILE.
  226 Transfer "complete"
  

  .

  (repeat this step for each file you want)
  
  ftp> quit 221 Goodbye.
  %
  
  Once you have the files, first unzip and untar them, and then configure, build, and install Perl:
  
  % gunzip < latest.tar.gz | tar xvf -
  % cd perl5.003 (Use actual directory name.)
  
  Now either one of these next two lines:
  % sh configure (Lowercase "c" for automatic configuration)
  % sh Configure (Capital "C" for manual configuration)
  
  % make (Build all of Perl.)
  
  % make test (Make sure it it works.)
  % make install (You should be the superuser for this.)
  Fetching modules
  For retrieving and building unbundled Perl modules, the process is slightly different. Let's say you want to build and install a module named CcolMod. You'd first fetch it via ftp(1), or you could use your Web browser to access the module service from http://wunv.perl.com/, which always retrieves the most up-to-date version of a particular registered module. The address to feed your browser would be something like:
  http://www.perl.com/cgi-bin/cpan_mod?module=CoolMod
  

  Once you've gotten the file, do this:

  % gunzip < CoolMod-2.34.tar.gz | tar xvf -
  % cd CoolMod-2.34
  % perl Makefile.PL (crates the real Makefile)
  

  % make (Build the whole module.)
  % make test (Make sure it works.)
  % make install (Probably should be the superuser)
  

  When the CoolMod module has been successfully installed (it will be automatically placed in your system's Perl library path), your programs can use CoolMod, and you should be able to run man CoolMod (or maybe perldoc CoolMod) to read the module's documentation.

  Conventions Used in This Book
  

  Since we pretty much made them up as we went along to fit different circumstances, we describe them as we go along, too. In general, though, the names of files and UNIX utilities are printed in italics, the names of Perl functions, operators, and other keywords of the language are in bold, and examples or fragments of Perl code are in constant width, and generic code terms for which you must substitute particular values are in italic constant width. Data values are represented by constant width in roman quotes, which are not part of the value.

  
  Acknowledgments
  

  This work would not have been possible without the help of a lot of folks. We can't possibly name everyone here, and undoubtedly we've overlooked at least one major contributor; but here are at least some of the folks that we'd like to thank publicly and profusely for their contributions of verbiage and vitality: llya Zakharevich, Johan Vromans, Mike Stok, Aaron Sherman, David Muir Sharnoff, Gurusamy Sarathy, Tony Sanders, Chip Salzenberg, Dean Roehrich, Randy J. Ray,

  Jon Orwant, Jeff Okamoto, Bill Middleton, Paul Marquess, John Macdonald, Andreas Koenig, Nick Ing-Simmons, Sharon Hopkins, Jarkko Hietaniemi, Felix Gallo, Hallvard B. Furuseth, Jeffrey Friedl, Chaim Frenkel, Daniel Faigin, Andy Dougherty, Tim Bunce, Mark Biggar, Malcolm Beattie, Graham Barr, Charles Bailey, and Kenneth Albanowski. Not necessarily in that order.

  The authors would also like to thank all of their personal friends (and relations) for remaining their personal friends (and relations) throughout the long, wearisome process.

  We'd like to express our special gratitude to Tim O'Reilly for encouraging authors to write the sort of books people might enjoy reading.

  Thanks also to the staff at O'Reilly & Associates. Steve Talbott was the technical editor. Nicole Gipson Arigo was the production editor and project manager. Joseph Pomerance was the copyeditor, and Steven Kleinedler proofread the book. Kismet McDonough- Chan and Sheryl Avruch performed quality control checks. Seth Maislin wrote the index. Erik Ray, Ellen Siever, and Lenny Muellner worked with the tools to create the book. Nancy Priest and Mary Jane Walsh designed the interior book layout, and Edie Freedman and Hanna Dyer designed the front cover.

  We'd Like to Hear from You
  

  We have tested and verified all of the information in this book to the best of our ability, but you may find that features have changed (or even that we have made mistakes!). Please let us know about any errors you find, as well as your suggestions for future editions, by writing:

  O'Reilly & Associates, Inc.

  101 Morris Street
  Sebastopol, CA 95472
  1-800-998-9938 (in the US or Canada)
  1-707-829-0515 (international/local)
  1-707-829-0104 (FAX)
  

  You can also send us messages electronically. To be put on the mailing list or request a catalog, send email to:

  [e-mail] (via the Internet) uanet!ora!info (via UUCP) To ask technical questions or comment on the book, send email to: [e-mail] (via the Internet)

  
  1 If you still get a humongous page when you do that, you're probably picking up the ancient Release 4 manpage. Check your MANPATH for archeological sites.

  
  2 Of course, some questions are too silly to answer, especially those already answered in the FAQ.

  3 The trailing tar.gz means that it's in the standard Internet format of a GNU-zipped, tar archive.

Editorial Reviews

Fatbrain Review

The definitive Perl 5 reference and user's guide, from the creator of Perl. An extensive overview is followed by details of syntax, terms, operators, pattern matching, formats, variables, and functions. Discusses references and nested data structures, packages, modules, object classes, social engineering (cooperation with other processes and languages), and, of course, the Standard Perl Library. For programmers unsure of their scripting prowess, we suggest two good companion volumes for this reference: Perl 5 Interactive Course by Orwant and Perl 5 How-To by Glover et al. The first is a comprehensive Perl tutorial, complete with your ezone mentor on the Web. The second is a practical guide, complete with problem solving scripting examples and excellent debugging and diagnostic procedures for this Pathologically Eclectic Rubbish Lister (aka Perl).

TMTOWTDI (There's More Than One Way To Do It)

How do you write the canon for a programming language that you created? Some writers will spend much of the reader's time trying to prove that their language is naturally superior because it was conceived by their superior mind. They are the ones that sprinkle their books with phrases like "as you can clearly see" as a preamble for ideas only understood by green-blooded science officers that say goodbye with "live long and prosper." Even among the humble, most write a reference book with the warmth of a logarithmic chart and the pathos of a decision table. But, in keeping with the Perl philosophy of TMTOWTDI, Wall shows us a more excellent way.

Programming Perl has warmth, personality, and, at unexpected times, brilliant wit. It feels like a explanation from a close friend. It even has a short section on Perl poetry.

How warm is it? Perl is the only language with an officially sanctioned thingy. A thingy, as defined by the authors, is "a value that is sort of like an object, that you may or may not know the name of, but that you can refer to via references from which the thingy dangles, metaphorically speaking." I don't feel quite so guilty now for checking the do-lollies in my C code by setting the warning level to puke-on-all.

Programming Perl is not an easy introduction to the language. This is especially true for the UNIX-challenged. The authors casually assume you know about things (or should I say thingies) like character block devices, UNIX-file permissions, and utmp files. If you expect a C> prompt when you sit down in front of a SUN -- start with a different book. Also, Programming Perl, like the language, is very dense. Complex ideas are compressed into the shortest space possible. What else would you expect from the folks that brought you the elusive and oft unseen $_ variable? If you are new to Perl and inherited a web site with Perl CGI scripts that must be changed by next Monday, try Learning Perl by Randal Schwartz instead.

While Programming Perl is not a good introduction, it is the definitive reference of the language. It is the one required book for all Perl programmers. It is the original source for syntax, semantics, and core functionality. It is the Perl version of The C Programming Language by Kernighan and Ritchie. It's the same thing, only funnier.--Dr. Dobb's Electronic Review of Computer Books

Donald Bryson