Learning Perl: 1.3. How Can I Get Perl?

 

1.3. How Can I Get Perl? 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. If you can't find it on your system, you can get it free. Perl is distributed under two different licenses. For most people who use Perl, either license is adequate. If you'll be modifying Perl, however, you'll want to read the licenses more closely because of the small restrictions on distributing the modified code. For people who won't modify Perl, the licenses say, "It's freehave fun with it." So, it's free and 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. Better yet, get your system administrator to type those two commands and install it for you.[*] Besides Unix and Unix-like systems, people have become addicted enough to Perl to port it to other systems, like the Macintosh,[*] VMS, OS/2, MS/DOS, every modern species of Windows, and probably more by the time you read this.[] Many of these ports of Perl come with an installation program that's easier to use than the process for installing Perl on Unix. Check for links in the "ports" section on CPAN. [*] 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 counteroffer with something as easy to get. [*] MacPerl runs under the "classic" Mac OS. If you have Mac OS X, which is a Unix-based system, you have mainstream Perl. [] And no, as we write this, it won't fit in your Palm handheld. It's just too darn big, even stripped down. We've heard rumors that it runs on WinCE, though. 1.3.1. What Is CPAN? CPAN is the Comprehensive Perl Archive Network, your one-stop shopping 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. [] It's nearly always better to compile Perl from the source on Unix systems. Other systems may not have a C compiler or other tools needed for compilation, so CPAN has binaries for these. 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, since 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. 1.3.2. How Can I Get Support for Perl? Well, you get the complete source, so you get to fix the bugs yourself. That doesn't sound so good, does it? But it 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 will probably have a fix for it. There are thousands of people around the world who help to 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 hopehopethat they fix the bug, hope that they fix it soon, and hope that they won't charge too much for the new version. You can hope the new version doesn't add new features with new bugs, and hope that the giant company doesn't get broken up in an anti-trust lawsuit. But with Perl, you've got the source. In the rare and unlikely event you can't get a bug fixed any other way, you can hire a programmer or ten and get to work. For that matter, if you buy a new machine that Perl doesn't run on yet, you can port it yourself. Or, if you need a feature that doesn't exist yet, well, you know what to do. 1.3.3. Are There Any Other Kinds of Support? 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 start one. Of course, for the first line of support, you shouldn't neglect the documentation. Besides the manpages,[*] you can find the documentation on the CPAN, http://www.cpan.org, as well as other sites, such as http://perldoc.perl.org that has HTML and PDF versions of the Perl documentation, http://www.perldoc.com that lets you search multiple versions of the documentation, or http://faq.perl.org/ that has the latest version of the perlfaq. [*] 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. Another authoritative source is O'Reilly's book Programming Perl, commonly called "the Camel book" because of its cover animal. (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-sized Perl 5 Pocket Reference by Johan Vromans (O'Reilly) that's handy to keep at hand (or in your pocket). If you need to ask a question, 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. [] Many mailing lists are listed at http://lists.perl.org. 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 with important announcements about Perl, including especially any security-related announcements. Ask your local expert if you need help with Usenet. A few web communities have sprung up around Perl discussions. One popular one, known as The 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. If you find yourself needing a support contract for Perl, a number of firms are willing to charge as much as you'd like. Most other support avenues will take care of you free. 1.3.4. What if I Find a Bug in Perl? 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 and not a bug. Check that you don't have an older version of Perl; maybe you found something that's been fixed in a more recent version. [*] Even Larry admits to consulting the documentation from time to time. [] Maybe even twice or three times. Many times, we've gone into the documentation looking to explain a particular unexpected behavior and found some new nuance that ends up on a slide or in a column. When you're almost 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 and not a bug. Once you're certain 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 as 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, you may 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 since 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.