Your Next Steps

Previous Table of Contents Next

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 with—discounting overlapping subjects—2,300 pages, and still some topics in Perl are not included.

A single resource can't cover all of Perl; however, the following sections provide recommendations for your next few steps.

The resources outlined here are presented roughly in the order in which 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 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 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 addressed, 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, you probably have a problem in your logic. Before you go tearing things apart, follow these steps:

Make sure that the #! line in your program contains a -w.

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, 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\n"


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. Also, 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 found 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, 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.8 release, more than 2,200 pages of documentation are 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 and tutorials.

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 might have differences.

If you cannot access 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 inline skating, along with regional groups for every region of the world. A few newsgroups are specific to Perl:


News about new Perl releases, modules, and information


Low-traffic group with moderated discussions about Perl


High-traffic discussion group about anything related 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 Web Archives such as groups.google.com 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 as follows: 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.

Google 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 groups.google.com's Advanced Search screen, and fill in the screen with the following:

Keywords:  fetch web page

Group:     comp.lang.perl.misc

For this example, leave all the other fields blank. When the search returns—with thousands of 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.

  • Google archives news for five or six years. Answers that may have been true five years ago may not be true 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 a genuinely good solution to your problem. However, unlike the other resources previously mentioned, 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, remember that you're borrowing that person's time and experience to get the answer to your question. It's your responsibility to do a reasonable amount of searching before asking someone else.

To ask a question in Usenet, you need to use a newsreader or one of the previously mentioned Web interfaces to Usenet News. As you're assembling your question, follow these guidelines:

  1. Before you do anything else, see whether the group has a Frequently Asked Questions (FAQ) list. The Perl groups do; it was shipped with your Perl interpreter. For any other group, search Google for the group's FAQ before posting a message.

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

  3. Pick a good subject line for your post. Subject lines should describe your problem, avoid useless phrases such as "help me" or "newbie question," and be descriptive but concise.

  4. Make sure that the body includes the following:

    1. A description of what you're trying to do (maybe even an explanation why)

    2. A description of what you've tried so far

    3. A description of the errors you've encountered

    For example, if you post error messages or references to your code, 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:

    1. Large code segments

    2. Postings of binaries such as .EXEs or uuencoded files

    3. MIME attachments (instead, include your examples and code in the body of the text)

  5. Make sure you post with a valid email address, in case someone wants to reply but not publicly.

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

Another Place to Look and Ask: PerlMonks

The PerlMonks web site (www.perlmonks.org) is another useful resource for Perl programmers. It's a fairly easy-to-navigate web message-board system that provides answers to Perl questions and discussion of Perl-related topics. Between 25 and 40 questions are answered daily in the "Seekers of Perl Wisdom" portion of the site and most questions are answered within 24 hours.

A wide range of people seek help at PerlMonks, from those just starting out with Perl to knowledgeable users who are looking for opinions on modules or articles before publication.

Like Usenet, those answering questions are all volunteers and have diverse backgrounds and experiences with Perl. As with any free resource, the quality and depth of answers can vary from response to response and from day to day.

In addition to the guidelines mentioned for Usenet, Tim Vroom who runs PerlMonks recommends a few more suggestions:

  • Try to find the answer first using Google to search Usenet, the Perl FAQs, and PerlMonk's search feature.

  • Realize that people are usually much more receptive to answering a question when it's clear you've put some effort into solving the problem yourself.

  • Use the "Chatterbox" feature—a live chat with other visitors to PerlMonks—to ask smaller and less involved questions, or get clarification on how to use the site.

  • Be sure to include any relevant code in your posting. Using <CODE></CODE> tags to surround your code will format it properly, and make it easy for others to download and test.

I've used this resource myself a few times to ask questions, and visited to answer questions on occasion, and I recommend it highly.

    Previous Table of Contents Next
    © 2000- NIV