Beginning CGI Programming with Perl

Preventing the Most Common CGI Bugs

Finding Things on Your System

One way to figure out where stuff is on your system is to use the whereis command. From the command line, type whereis perl. The system searches for the command (perl) in all the normal system directories where commands can be found and returns to you the directory in which the Perl interpreter resides.

If this doesn’t work for you, try typing the which command. Type which perl from the command line. The which command searches all the paths in your path variable and returns the first match for the command.

If neither of these methods works, try using the find command. Change directories to one of the top-level directories (starting at /usr/local, for example).

At the prompt cd /usr/local, type find . -name perl -print. This command searches all the directories under the current directory, looking for a file that matches the file in the -name switch end.

Make Your Program Executable

After you tell the system which interpreter to run and where it is, what next? Well, the next most common mistake is forgetting to set the file permissions correctly. Is your program executable? Even if everything else about the program is right, if you don’t tell the server that your program is executable, it will never work! You might know that it’s a program, but you’re not supposed to keep it a secret from the server.

Enter ls -l at the command line. If you see the following message, you forgot to change the file permissions to executable:

-rw-rw-rw- program.name

Don’t be too chagrined by this; I wouldn’t mention it if it didn’t happen all the time. It’s really frustrating when you’ve been doing this for 10 years and you still forget to set the file permissions correctly. What’s embarrassing, though, is asking someone why your program doesn’t work, and the first thing she checks are your file permissions. The look you get from your Web guru when your file isn’t executable just makes you want to go hide under a rock. Don’t do this one to yourself; always check your file permission before asking someone else what is wrong with your program. Then set your program’s file permissions to something reasonable like this:

> chmod 755 program.name

Most of your CGI programs can use a print line just like this:

print "Content-Type: text/html\n\n";

The \n at the end of the HTTP response header prints a newline character. The server knows that your CGI program has sent its last response header when it finds a blank line after an HTTP response header. After that blank line, it is expecting to find the content type your program described in the Content-Type response header.

There is still one bug that usually bites the more experienced programmers more often than the inexperienced folks. The filename extension must be correct. We experienced (old) guys and gals know that the filename extensions don’t really mean anything, so we are more likely to ignore the file-naming convention of filename.cgi for CGI programs. This is a big mistake! The Web server really does use that filename extension to determine what it is supposed to do with the file requested by the browser. So use the correct file extension! It’s probably .cgi, but check the srm.conf file found below the server root directory in the configuration directory because it has the correct file extension. Look for something like this:

AddType application/x-httpd-cgi .cgi

You will save a great deal of debugging time if you always check these things first:

• Always check your file permissions; your CGI program should be executable.
• Always try your program first from the command line.
• Make sure that you are sending a blank line after your last response header.
• Make sure that the filename extension on your CGI program matches the one in the srm.conf file.