Your Next Steps
After reading though the first two-thirds of this book, you should have an understanding of the basics of Perl. You have by no means learned the whole language. On my bookshelf are at least half a dozen books on the Perl language that cover—discounting overlapping subjects—Perl in 2,300 pages, and still some topics in Perl are not included.
You won't find a single resource for learning all of Perl; however, the following sections recommend your next few steps.
The resources outlined here are presented roughly in the order you should seek them out. There are exceptions, but for the most part, following this order will solve your problems in the quickest manner possible.
Your First Step
When you have a Perl problem, trying to figure out what to do first is tough. You're frustrated, and if you've been working on the problem for a little while, you're probably upset. Take a deep breath, don't panic, and convince yourself that everything will be all right. Believe it or not, this is an important first step. Most people will become blocked on a problem after a while, and all the frustration from being blocked will prevent clear thinking, so you might wind up making things worse.
Walk away, get something to drink, calm down, and relax. You will solve this problem.
Your Most Useful Tool
The most useful tool in your Perl toolbox is Perl itself. First, you need to determine what kind of problem you have. Usually, problems fall into just two categories: faulty syntax or bad and incomplete logic.
If you have a problem with syntax, you can usually break it down into two smaller problems: Either you're using some bit of Perl incorrectly, or you've made a typo. Run your program, and examine the error message; it usually indicates Perl's best guess as to which line is wrong. Look at the line for any of the following:
Does Perl's error message indicate specifically where you should look? Look there! The Perl interpreter can be your best ally in finding bugs.
Do all the open parentheses, brackets, and braces have matches somewhere?
Did you check your spelling carefully? Check it again. You'd be surprised at how many bugs turn out to be spelling errors.
Did you leave something out? A comma, a period?
Do the lines immediately before the indicated line look okay?
If you go back to the section in this book where that particular type of syntax was talked about, can you find examples that look similar to yours?
If you copied the code from another source, did you check someplace else for a similar piece of code? Mistakes happen.
If your Perl program runs but simply doesn't produce the right results, then you probably have a problem in your logic. Before you go tearing things apart, follow these steps:
Make sure you have use strict somewhere near the top of your program.
Many apparent logic problems turn out to be simple mistakes that -w and use strict will catch. Use them, and if you still have problems, read on.
Debug Your Program
If you're certain that the syntax of your program is right, but it's just not doing the right thing, then it's time for some elementary debugging.
The first, and probably most used, technique in debugging a program is to use the lowly print statement. Used carefully in your programs, it can provide some runtime diagnostics as to what's going on. Look how print operates in this example:
sub foo {
my($a1, $a2)=@_;
# Diagnostic added to see if everything's OK.
print STDERR "DEBUG: Made it to foo with $a1 $a2
"
}
Just remember that when your program is complete, you need to take out all the debugging print statements. I recommend putting some kind of string in them ("DEBUG") so that you can find them all later. And by printing to the STDERR filehandle, you can separate your normal output from the diagnostics. If you include the literal symbols __LINE__ and __FILE__ in your diagnostic message, Perl will print the name of the current line and file.
The other approach you should try is to use the Perl debugger. You can use the debugger on almost any Perl program. Watching your program run step-by-step can be very enlightening. Instructions for using the Perl debugger are in Hour 12, "Using Perl's Command-Line Tools."
First, Help Yourself
If your syntax is all right, and your logic seems to be okay, but you're just not getting the results you want, then it might be time to seek outside help. The first place you should look for answers is in the Perl documentation.
As indicated in Hour 1, "Getting Started with Perl," every Perl installation comes with a full set of documentation. For the 5.005 release, more than 1,700 pages of documentation were included with the distribution. Every module, every function, and most aspects of the Perl language are covered in this documentation, as well as a large Frequently Asked Questions list.
To get a list of the available documentation, type perldoc perl at a command prompt. Each of the manual sections is listed, as well as a general description of Perl.
The Frequently Asked Questions list contains a list of the most commonly asked questions that beginners—and experts—have about the Perl language. It's worth browsing at least once, to get an idea of what kinds of questions are there, even if you don't completely understand the answers yet.
If, for some reason, you do not have the Perl documentation installed on your system or perldoc does not present the documentation, you should first talk to your system's administrator to find the documentation. Having the documentation correctly installed is important because the online documentation matches the version of Perl you're running. Any other documentation is likely to have differences.
If you cannot get access to the online documentation, you also can find the documentation at http://www.perl.com.
Learn from the Mistakes of Others
Usenet is a distributed messaging system that was developed in the early 1980s and spread to the fledgling Internet. Usenet is divided into tens of thousands of discussion groups, with topics ranging from meditation, gardening, computing, and science fiction to hockey and roller-blading, along with regional groups for every region of the world. A few newsgroups are specific to Perl:
To read Usenet news, you need a newsreader, and newsreaders are not hard to find. You can go to any software download site and grab a newsreader. You can also go to several Web sites—deja.com or supernews.com, for example—that mirror the Usenet newsgroups in a Web format and require only that you have a Web browser to read news.
In these newsgroups, people post questions about problems that they're having with Perl, and other people answer the questions—all on a voluntary basis. Also, discussions about general-interest topics related to Perl take place here.
An observation that has held true through my entire programming career is: There are no original problems in computing. Any problem that you are having, someone else has had before. The trick is finding who asked the question and what answer that person found. It's very likely that at least one person has asked a remarkably similar question to yours in one of these newsgroups.
deja.com maintains an online history for much of Usenet. Using its search engine, with a few well-chosen keywords, you'll likely find the answers to your question.
For example, say that you want to know how to write a Perl program to fetch a Web page. Go to deja.com's Power Search screen, and fill in the screen with the following:
Keywords: fetch web page Forum: comp.lang.perl.misc
For this example, leave all the other fields blank. When the search returns—with almost 100 matches—most of the matches will have to do with the topic you asked about. You should remember a few points about the articles that you read in Usenet:
Not all the answers are correct. Anyone can ask a question, and anyone can answer it. Read a few responses, and decide for yourself which ones seem authoritative. Your mileage will vary.
If you're unsure about whether an answer is correct, use the answer as a starting place to check the information yourself. Go read manual pages on the topic now that you know where to look.
deja.com archives news for five years. Answers that may have been true five years ago may be deprecated now.
When All Else Fails, Ask
If you've checked the online documentation, your books, and Usenet history, and you still don't have an answer to your question, you might need to ask someone.
Asking for help should be your last resort, certainly not your first. Experts are a unique medium for answering questions. They can take your badly phrased question and sometimes come up with genuinely good solutions to your problems. Unlike all the other resources I mentioned, however, people do not have an unlimited capacity for answering questions. They will get tired, they will have bad days, and they will especially get tired of answering the same questions over and over.
Although it's very likely that the person you're asking may know the answer, just remember that you're borrowing that person's time and his or her experience to get the answer to your question. It's your responsibility to have done a reasonable amount of searching before bothering someone else.
To ask a question in Usenet, you need to use a newsreader or one of the previously mentioned Web interfaces to news. As you're assembling your question, follow these guidelines:
Before you do anything else, see whether the group has a Frequently Asked Questions list. The Perl groups do; it was shipped with your Perl interpreter. For any other group, search deja.com for the group's FAQ before posting a message.
Post the question to the correct newsgroup. A general Perl language question should be posted to the group comp.lang.perl.misc. A CGI-specific programming question should probably be posted to comp.infosystems.www.authoring.cgi. By reading the FAQ for the group, you'll know whether you're posting to the right place.
Pick a good subject line for your post. It should describe your problem, avoid useless text ("help me" or "newbie question" are useless in a subject), and be descriptive but concise.
Make sure that the body includes the following:
A description of what you're trying to do (maybe even a description why)
A description of the errors you've encountered
If you post error messages or references to your code, for example, you should also include enough of your code so that the responders can tell what's going on. If you're trying to process data, include a few lines for an example.
The body should not include the following:
Large code segments.
Postings of binaries such as .EXEs or uuencoded files.
MIME attachments. Instead, include your examples and code in the body of the text.
Make sure you post with a valid email address, in case someone wants to reply but not publicly.
Above all, be polite. You are asking for the kindness of strangers. No one is obligated to help you. Say "please" and "thank you," and avoid inflammatory remarks. Don't use gimmicks to try to get help—for example, "Help a poor little girl with her CGI program…" or "I'll give you a free Web page if you…" These gimmicks are rude and demeaning.
After you post your article to the newsgroup, wait. Usenet news can take a few days to propagate to the entire world, and people don't always keep up and read every article. Be patient, and go on to the next problem while you wait. Whatever you do, do not post to Usenet again with your question too soon. Wait at least a couple of weeks before asking again. Rephrase your question, make sure your subject line is clear, and then try again.
The responses to your article can start immediately (within a few minutes) or could show up a month or more after you posted. As I said before, the quality of the responses will vary greatly. Some will be informative, and others will be wrong. Some respondents will be gracious and polite, and others will be exceedingly rude. It's considered good Netiquette to thank the responders and ignore any flames you've received.