 |  |
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.[20] But if you can't find it already on your system, you can still get it for free.
[20]Well, each machine that is made for programming, at least.
Perl is distributed under two different licenses. For most people, since 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.[21]
[21]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.
Besides Unix and Unix-like systems, people have also been addicted enough to Perl to port it to other systems, like the Macintosh,[22] VMS, OS/2, even MS/DOS and every modern species of Windows -- and probably even more by the time you read this.[23] 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.
[22]MacPerl runs under the "classic" Mac OS. If you have Mac OS X, which is a Unix-based system, you have mainstream Perl.
[23]And no, as we write this, it won't fit in your Palm handheld -- it's just too darn big, even stripped down.
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,[24] examples, documentation, extensions to Perl, and archives of messages about Perl. In short, CPAN is comprehensive.
[24]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.
CPAN is replicated on hundreds of mirror machines around the world; start at http://www.cpan.org/ to find one near you. Most of the time, you can also simply visit http://COUNTRYCODE.cpan.org/ where COUNTRYCODE is your two-letter official country code (like on the end of your national domain names). Or, 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.)
CPAN is pretty-well organized; most of the time, you should find what you want with just a few clicks of the mouse. But there's also a couple of nice search interfaces on the Web at http://search.cpan.org/ and http://kobesearch.cpan.org/,which are especially helpful when you're looking for an extension to 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 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 has probably already got 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.[25]
[25]Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a 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 anti-trust 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 ten 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[26] themselves, Perl's documentation includes the voluminous FAQ (Frequently Asked Questions) and many tutorials.
[26]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. If you can't find them anywhere else, the manpages are available directly on CPAN.
Another authoritative source is the book Programming Perl, commonly known as "the Camel book" because of its cover animal (just as this book has come to be 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 quick reference to Perl (by Johan Vromans) that's handy 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.[27] At any hour of the day or night, there's a Perl expert awake in some timezone 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.
[27]Many mailing lists are listed at http://lists.perl.org.
We generally recommend the newsgroup comp.lang.perl.moderated, where (as the name implies) a moderator will check over your question before posting it. If there's something wrong with your question, you'll still get flamed of course, but it's a small, private flame in email rather than a big public one in a newsgroup.[28] But for most questions, you'll get an answer back within the hour. Just try getting that level of support from your favorite software vendor for free!
[28]Of course, we're joking here. Unless you've done something amazingly boneheaded, the moderators are all kind, polite, helpful folks, who will gently point you in the direction of the information you need, with just enough flame to remind you to be more careful next time. Don't be afraid to ask.
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, 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 one of the authors of this book.
If you find yourself needing a support contract for Perl, there are a number of firms who 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[29] again.[30] 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.
[29]Even Larry admits to consulting the documentation from time to time.
[30]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 little nuance that ends up on a slide or in a column.
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 (if 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, 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.
|  | |
| 1.2. What Does "Perl" Stand For? |  | 1.4. How Do I Make a Perl Program? |
Copyright © 2002 O'Reilly & Associates. All rights reserved.