You probably already have it. At least, we find Perl wherever we go. It ships with many systems, and system administrators often install it on every machine at their site. But if you can’t find it already on your system, you can still get it for free.
Perl is distributed under two different licenses. For most people, because you’ll merely be using it, either license is as good as the other. If you’ll be modifying Perl, however, you’ll want to read the licenses more closely because they put some small restrictions on distributing the modified code. For people who won’t modify Perl, the licenses essentially say, “It’s free—have fun with it.”
In fact, it’s not only free, but it runs rather nicely on nearly everything that calls itself Unix and has a C compiler. You download it, type a command or two, and it starts configuring and building itself. Or, better yet, you get your system administrator to type those two commands and install it for you.[*] Besides Unix and Unix-like systems, people have also been addicted enough to Perl to port it to other systems, such as Mac OS X, VMS, OS/2, even MS/DOS, and every modern species of Windows—and probably even more by the time you read this.[†] Many of these ports of Perl come with an installation program that’s even easier to use than the process for installing Perl on Unix. Check for links in the “ports” section on CPAN.
CPAN is the Comprehensive Perl Archive Network, your one-stop shop for Perl. It has the source code for Perl itself, ready-to-install ports of Perl to all sorts of non-Unix systems,[‡] examples, documentation, extensions to Perl, and archives of messages about Perl. In short, CPAN is comprehensive.
CPAN is replicated on hundreds of mirror machines around the world; start at http://search.cpan.org/ or http://kobesearch.cpan.org/ to browse or search the archive. If you don’t have access to the Net, you might find a CD-ROM or DVD-ROM with all of the useful parts of CPAN on it; check with your local technical bookstore. Look for a recently minted archive, though. Because CPAN changes daily, an archive from two years ago is an antique. Better yet, get a kind friend with Net access to burn you one with today’s CPAN.
Well, you get the complete source—so you get to fix the bugs yourself!
That doesn’t sound so good, does it? But it really is a good thing. Since there’s no “source code escrow” on Perl, anyone can fix a bug—in fact, by the time you’ve found and verified a bug, someone else probably already has a fix for it. There are thousands of people around the world who help maintain Perl.
Now, we’re not saying that Perl has a lot of bugs. But it’s a program, and every program has at least one bug. To see why it’s so useful to have the source to Perl, imagine that instead of using Perl, you licensed a programming language called Forehead from a giant, powerful corporation owned by a zillionaire with a bad haircut. (This is all hypothetical. Everyone knows there’s no such programming language as Forehead.) Now think of what you can do when you find a bug in Forehead. First, you can report it; second, you can hope—hope that they fix the bug, hope that they fix it soon, hope that they won’t charge too much for the new version. You can hope that the new version doesn’t add new features with new bugs, and hope that the giant company doesn’t get broken up in an antitrust lawsuit.
But with Perl, you’ve got the source. In the rare and unlikely event that you can’t get a bug fixed any other way, you can hire a programmer or 10 and get to work. For that matter, if you buy a new machine that Perl doesn’t yet run on, you can port it yourself. Or if you need a feature that doesn’t yet exist, well, you know what to do.
Sure. One of our favorites is the Perl Mongers. This is a worldwide association of Perl users’ groups; see http://www.pm.org/ for more information. There’s probably a group near you with an expert or someone who knows an expert. If there’s no group, you can easily start one.
Of course, for the first line of support, you shouldn’t neglect the documentation. Besides the manpages,[*] you can also find the documentation on the CPAN (http://www.cpan.org) as well as other sites, such as http://perldoc.perl.org, which has HTML and PDF versions of the Perl documentation, or http://faq.perl.org/, which has the latest version of the perlfaq.
Another authoritative source is the book Programming Perl, commonly called “the Camel book” because of its cover animal (just as this book is known as “the Llama book”). The Camel book contains the complete reference information, some tutorial stuff, and a bunch of miscellaneous information about Perl. There’s also a separate pocket-size Perl 5 Pocket Reference (O’Reilly) by Johan Vromans that’s convenient to keep at hand (or in your pocket).
If you need to ask a question of someone, there are newsgroups on Usenet and any number of mailing lists.[†] At any hour of the day or night, there’s a Perl expert awake in some time zone, answering questions on Usenet’s Perl newsgroups—the sun never sets on the Perl empire. This means that if you ask a question, you’ll often get an answer within minutes. If you didn’t check the documentation and FAQ first, you’ll get flamed within minutes.
The official Perl newsgroups on Usenet are located in the comp.lang.perl.* part of the hierarchy. As of this writing, there are five of them, but they change from time to time. You (or whoever is in charge of Perl at your site) should generally subscribe to comp.lang.perl.announce, which is a low-volume newsgroup just for important announcements about Perl, including especially any security-related announcements. Ask your local expert if you need help with Usenet.
Also, a few web communities have sprung up around Perl discussions. One very popular one, Perl Monastery (http://www.perlmonks.org), has seen quite a bit of participation from many Perl book and column authors, including at least two of the authors of this book. You can also check out http://learn.perl.org/ and its associated mailing list, beginners@perl.org. For Perl news, try http://use.perl.org/. Many well-known Perl programmers also have blogs that regularly feature Perl-related posts, most of which you can read through http://planet.perl.org.
If you find yourself needing a support contract for Perl, there are a number of firms that are willing to charge as much as you’d like. In most cases, these other support avenues will take care of you for free.
The first thing to do when you find a bug is to check the documentation[*] again.[†] Perl has so many special features and exceptions to rules that you may have discovered a feature, not a bug. Also, check that you don’t have an older version of Perl; maybe you found something that’s been fixed in a more recent version.
Once you’re 99% certain that you’ve found a real bug, ask around. Ask someone at work, at your local Perl Mongers’ meeting, or at a Perl conference. Chances are, it’s still a feature, not a bug.
Once you’re 100% certain that you’ve found a real bug, cook up a test case. (What, you haven’t done so already?) The ideal test case is a tiny self-contained program that any Perl user could run to see the same (mis)behavior you’ve found. Once you’ve got a test case that clearly shows the bug, use the perlbug utility (which comes with Perl) to report the bug. That will normally send email from you to the Perl developers, so don’t use perlbug until you’ve got your test case ready.
Once you’ve sent off your bug report, if you’ve done everything right, it’s not unusual to get a response within minutes. Typically, you can apply a simple patch and get right back to work. Of course, you may (at worst) get no response at all; the Perl developers are under no obligation to even read your bug reports. But all of us love Perl, so nobody likes to let a bug escape our notice.
[*] If system administrators can’t install software, what good are they? If you have trouble convincing your admin to install Perl, offer to buy a pizza. We’ve never met a sys admin who could say no to a free pizza, or at least counter-offer with something just as easy to get.
[†] And no, as we write this, it won’t fit in your Blackberry—it’s just too darn big, even stripped down. We’ve heard rumors that it runs on WinCE though.
[‡] It’s nearly always better to compile Perl from the source on Unix systems. Other systems may not have a C compiler and other tools needed for compilation, so CPAN has binaries for these.
[*] The term manpages is a Unix-ism meaning documentation. If you’re not on a Unix system, the manpages for Perl should be available via your system’s native documentation system.
[†] Many mailing lists are listed at http://lists.perl.org.
[*] Even Larry admits to consulting the documentation from time to time.
[†] Maybe even two or three times. Many times, we’ve gone into the documentation looking to explain a particular unexpected behavior and found some new little nuance that ends up on a slide or in a column.
Get Learning Perl, 5th Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
