The error_log is not made available to users because of its sheer
volume and 99% uselessness. However, there is a wide variety of approaches
that you can take for debugging your CGI scripts; taken together, they
provide much greater power and flexibility than the error_log
alone.
Most CGI problems arise when a script will not execute
successfully, if at all.
If your CGI script won't run at all, the Web server will fail to execute
the script at all, and will return "Server Error" or
"Permission Denied".
If the
script does execute, but dies prematurely or generates anything other than
standard HTTP headers (such as error messages, for example), the Web server
has no choice but to simply give up.
The most common causes of a non-executing script are:
- Uploading a text CGI script (usually a Perl script) in binary mode from
a PC or Macintosh. These systems use a different linefeed convention from
Unix, and you must set your FTP client to ASCII or text mode when uploading
them. If you do not, the first line of the script will not be correctly
read by the system to specify the path to the interpreter, and attempting
to execute the script will generate a "File not Found" type of
error (which may still be reported as "Server Error").
- Failing to set the executable bits on the script. This is done with
the command chmod 755 filename via Telnet or the more complex
quote site chmod 755 filename via FTP (your client may have its
own interface for this).
- Using the wrong URL to reach your script. The URL should resemble
http://www.domain.com/cgi-bin/filename
- An interpreted script with syntax or other parsing errors. The
interpreter (usually Perl) must be able to correctly understand all of your
script. Although the script is not fully compiled by the interpreter
before executing, it is parsed and any syntax errors will be found and
reported. To see if this is happening, execute
your script from the shell (see below).
- Run-time errors. If your script executes, but attempts something that
fails, it will exit prematurely or generate error messages that interfere
with the HTTP headers the Web server is expecting. This is most often
caused by insufficient permissions. It may also be caused by programmer error, in which case you should debug your script from the shell (see below).
To execute your script from the shell (reached by Telnet), go to the
directory where the script is stored, and execute it with:
cactus~:$ ./scriptname.cgi
The "./" portion is required, because "." is not
normally in your path, for security reasons.
If your script fails to execute at all, you may see:
./scriptname.cgi: Command not found.
This can indicate that the script itself was not found (check your
directory and filename), or that the interpreter specified in its first
line could not be found. If the interpreter was not found, the most
common cause is a file corrupted by a binary mode FTP transfer (see above).
You may also have an incorrect path. For Perl 5.004_004, use
#!/usr/bin/perl. For the Bourne shell, use
#!/bin/sh. For any other program or interpreter that you need to
find, use the
which command.
You may instead see:
./scriptname.cgi: Permission denied.
This indicates that you do not have the correct permissions set. Correct
this by typing chmod 755 scriptname.cgi, and trying again.
If the interpreter fails to parse your script, you will see results such
as:
syntax error at ./scriptname.cgi line 3, near "while 1"
Execution of ./scriptname.cgi aborted due to compilation errors.
username%
This tells you where to look in your script for a programming error.
You may also receive
a system error such as Segmentation fault, Memory
fault, Bus error, etc, possibly including the phrase
(core dumped). These are usually seen with programming errors in
compiled C programs. To work on these, you'll need to enable core dumps
(with unlimit coredumpsize or by editing your .cshrc),
compile your program with debugging flags (usually -g will
suffice), and use a debugger such as gdb. For more information on
gdb, please visit its
tutorial.
Finally, your program may execute successfully, but immediately complain
because it is not being run from the Web, usually because there was no way
of getting the CGI query parameters, or other variables such as the remote
host address. In this case, you need to simulate the CGI environment from
the command line.
