Ships from: Miamisburg, OH
Usually ships in 1-2 business days
Ships from: Niagara Falls, NY
Usually ships in 1-2 business days
Ships from: Spring Hill, KS
Usually ships in 1-2 business days
Ships from: Holmdel, NJ
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Programming Perl, 2nd Edition is the authoritative guide to Perl version 5, the scripting utility that has established itself as the programming tool of choice for the World Wide Web, UNIX system administration, and a vast range of other applications. Version 5 of Perl includes object-oriented programming facilities. The book is coauthored by Larry Wall, the creator of Perl.
Perl is a language for easily manipulating text, files, and processes. It provides a more concise and readable way to do many jobs that were formerly accomplished (with difficulty) by programming with C or one of the shells. Perl is likely to be available wherever you choose to work. And if it isn't, you can get it and install it easily and free of charge.
This heavily revised second edition of Programming Perl contains a full explanation of the features in Perl version 5.003. Contents include:
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).
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
...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 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.)...
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 BookHere'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).
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 NewsgroupsThe 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 HomepageIf 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.
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.
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 DistributionPerl 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.
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 PerlThe 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:
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:
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.30The 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 AreUnder the main CPAN directory, you'll see at least the following subdirectories:
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).
(repeat this step for each file you want)Once you've gotten the file, do this:
% gunzip < CoolMod-2.34.tar.gz | tar xvf -% 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.
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.
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 YouWe 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 StreetYou can also send us messages electronically. To be put on the mailing list or request a catalog, send email to:
nuts@ora.com (via the Internet) uanet!ora!info (via UUCP) To ask technical questions or comment on the book, send email to: bookquestions@ora.com (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.
3 The trailing tar.gz means that it's in the standard Internet format of a GNU-zipped, tar archive.
Anonymous
Posted February 20, 2000
I have been a Perl programmer for the last two years and I thought it is now a good time to buy a reference book in Perl. Obviously my choice was 'Learning Perl' by Larry Wall. Content is good, as a reference it is excellent, as a study book it is weak and it is not at all good for the beginners. At some places you may feel the language need not be this artistic. I wished that the book contained more examples and a little more detail on how to use PERL functions. I have been looking into various Perl books which are good for people good in Perl (some sort of reference + as a study book). One book which is worth mentioning is Perl Black Book. If you wish to buy only one book in PERL -- The 'Perl Black Book' is the best one. It is equally good for beginners and experts.. have enough examples, goes into details about everything and does not miss out anything.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Overview
Programming Perl, 2nd Edition is the authoritative guide to Perl version 5, the scripting utility that has established itself as the programming tool of choice for the World Wide Web, UNIX system administration, and a vast range of other applications. Version 5 of Perl includes object-oriented programming facilities. The book is coauthored by Larry Wall, the creator of Perl.
Perl is a language for easily manipulating text, files, and processes. It provides a more concise and ...