Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Programming PERL

Programming PERL

by Tom Christiansen

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


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:

  • An introduction to Perl
  • Explanations of the language and its syntax
  • Perl functions
  • Perl library modules
  • The use of references in Perl
  • How to use Perl's object-oriented features
  • Invocation options for Perl itself, and also for the utilities that come with Perl
  • Other oddments: debugging, common mistakes, efficiency, programming style, distribution and installation of Perl, Perl poetry, and so on.

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).
Donald Bryson

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

Product Details

O'Reilly Media, Incorporated
Publication date:
Nutshell Handbooks Series
Edition description:
Second Edition
Product dimensions:
7.08(w) x 9.20(h) x 2.74(d)

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.)...

Meet 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.

Randal L. Schwartz is a two-decade veteran of the software industry. He is skilled in software design, system administration, security, technical writing, and training. Randal has coauthored the "must-have" standards: Programming Perl, Learning Perl, Learning Perl for Win32 Systems, and Effective Perl Learning, and is a regular columnist for WebTechniques, PerformanceComputing, SysAdmin, and Linux magazines.

He is also a frequent contributor to the Perl newsgroups, and has moderated comp.lang.perl.announce since its inception. His offbeat humor and technical mastery have reached legendary proportions worldwide (but he probably started some of those legends himself). Randal's desire to give back to the Perl community inspired him to help create and provide initial funding for The Perl Institute. He is also a founding board member of the Perl Mongers (perl.org), the worldwide Perl grassroots advocacy organization. Since 1985, Randal has owned and operated Stonehenge Consulting Services, Inc. Randal can be reached for comment at merlyn@stonehenge.com or (503) 777-0095, and welcomes questions on Perl and other related topics.

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.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews