Errors are divided into six main categories (listed by degree of difficulty):
File format errors
In Unix and Windows operating systems, different characters are used to terminate a line.
This can cause problems if you edit your program in one type of operating system and then run it in another OS. In other words, if you create and edit your programs on Windows, and your ISP uses a Unix-based Web server, you need to make sure that your program file is saved with the appropriate line separators.
One easy way to do this is to open the file on your Web server and see if there are any strange characters at the end of each line.
Just be sure that your editor shows special characters.
For example, the vi editor shows them, but the less editor does not.
Many modern text editors provide the ability to set the type of line separators, so check that you are saving the file in a format suitable for your Web server.
If you are sending files to your Web server using FTP, make sure that your FTP client is configured to send files in ASCII text mode and not binary mode. In many cases, this ensures that line breaks are automatically converted and helps avoid problems.
Errors accessing files and the Perl interpreter
We recommend that you display Perl interpreter errors when testing the script in your browser window. To set this mode for debugging time, you need to enter at the beginning of the script:
use CGI::Carp 'fatalsToBrowser';Первая строка вашего скрипта должна указывать путь к интерпретатору Perl:
#!/usr/bin/perlMake sure there is no carriage return character (code 0x0D), and only line feed characters (code 0x0A) should be present in the script lines. The rights for CGI scripts, as well as for the directory containing the scripts, must be set to “-rwxr-xr-x”, for example with the following command:
chmod 755Syntax errors
Perl has a special tool that allows you to check a program for syntax errors from the command line. On Unix or Windows (using the DOS command processor), this is done by entering the following line at the OS prompt:
perl -с <your_scritp>.cgiRegardless of which operating system you are using, if there are syntax errors, you will receive a message listing all the errors Perl found. For example, a message taken from a simple program where the closing quote is missing at the end of the line:
#can't find string terminator '"' anywhere before EOF
file '<your_scritp>.cgi'; line 3Once you receive information about errors, enter the program, make the necessary corrections and continue testing the program until the errors disappear.
Once you've finished making adjustments, try running the program from the command line without using the -c switch and see if it produces the correct standard information. (This may be an HTML error page if the program is waiting for form input.)
Note: Be sure to continue testing with this technique until Perl stops producing error messages. Some errors may be hidden by others; in this case, Perl will report hidden errors only when all others have been resolved.
Configuration errors
The program can be configured using a set of configuration variables that are defined either at the beginning of the program or in a separate configuration file. Some of these variables are intended to configure program options, while others indicate the location of various support files. (This approach makes it easier to customize the behavior of the program without making changes to the code).
If variables that primarily point to external files are not set correctly, or if they point to resources that are unavailable for some reason, the program generates an error. When using variables that set files, you need to check whether these files exist and whether they have the appropriate access permissions.
Output format errors
The last type of error that you need to make sure is absent before calling the program from the browser is an output format error. All CGI program output to the visitor's Web browser (i.e., everything output to STDOUT) must be preceded by a valid HTTP header, otherwise a "500 Server Error" will be generated.
For example, if you are generating an HTML page, the first print statement the program executes should be:
print "Content-Type: text/html\n\n";This statement outputs an HTTP header indicating that the information that follows will contain an HTML page. If you remember to put this line (or the corresponding HTTP header when outputting a non-HTML page) before all other print statements in your program, you will avoid any output format errors.
Errors in program logic (using the Perl debugger)
If you have checked the program for the presence of errors of all categories named in the previous sections, then you may only have errors related to the program logic. There are two ways to detect these types of errors: using diagnostic messages and using a Perl debugger.
Launching the Debugger
If you are using Perl under Unix or Windows (with a DOS shell), then the debugger is launched by executing the program as follows:
perl -d program.cgiThe -d flag tells Perl to enable the debugger. You will receive several messages followed by a debugger prompt that looks something like this:
main::(<ваш_скрипт>.cgi:4): $test_file = "/home/web/test.html";
DB<1>The top line of the debugger message displays the contents of the next line to be executed. The bottom line is the invitation itself; it lets you know that the debugger is ready to receive commands.
How to get help
Debugger commands consist of one or two characters, sometimes followed by an optional or required argument.
A complete list of these commands can be obtained by typing h at the debugger prompt and pressing Enter.
Step-by-step passage of the program
Basic debugger commands allow you to process a program one line at a time. If you type s at the debugger prompt and press Enter, Perl will execute the next line of the program and issue a new prompt.
If you enter the command n and press the Enter key, Perl will do the same thing, but will skip the subroutine calls. (The s command takes you into a subroutine). If you have used any of these commands at least once, then to call it again you just need to press the Enter key.
View values
At any time while working with the debugger, you can check the values of variables. There are several methods for this purpose.
Typing the command X and the variable name (without the type specifier (S, %, or @) at the beginning) and then pressing Enter will cause Perl to produce a list of variables (using the variable name) with their values in a convenient format. This will allow you to see the contents of arrays and associative arrays.
You can also use a standard print statement, such as print $var__name. In principle, any valid Perl operator can be used at the debugger prompt.
Search for a string
If you have already traced the error to a specific segment of the program, then you probably want to immediately jump to that point and start searching there. The debugger provides several ways to navigate within a program. The first is to use the l command, which allows you to display a specific line number. For example:
DB<1> 1 180This command will cause the debugger to display line 180. By omitting the line number, a group of lines can be displayed on the screen. You can also display a range of rows:
DB<2> 1 180-200Using the w command, you can display a group of lines with the current line or a given line in the middle of the group to place a specific line in context:
DB<3> w 180This command displays a group of lines with line 180 in the middle. If the line number is not specified, then the current line number is used. The second way to go to a specific point in the program is a standard search using the following example:
DB<4> \/$count/This command searches the program for the next instance of the Scount variable and jumps to the line that contains it. (The closing oblique can be omitted).
Breakpoints
If you do not want to move through the program step by step, then to get to the desired line, you can set a breakpoint in it. A breakpoint will instruct Perl to execute the program up to this line, then stop and wait for your next command:
DB<5> b 180This command causes the program to pause when it reaches line 180. (To start the program or resume it after an interruption, use the c command). You can also specify a condition that must be met for the program to abort. For example:
DB<6> to 180 $count > 5This command causes the program to pause when it reaches line 180. (To start the program or resume it after an interruption, use the c command). You can also specify a condition that must be met for the program to abortion. For example:
DB<7> d 180Executing additional commands
The last of the commands allows you to specify an action that should be performed on the specified line without stopping the execution of the program. For example:
DB<8> a 180 print $count;This command will cause the debugger to print the current value of the $count variable immediately before executing line 180.
Undoing actions is done by command A (it cancels all actions that you have set for the program).
Simulating a CGI call
The Perl debugger can be used with a CGI program. CGI programs are executed in remote mode, so there is no access to a debugger. However, it is possible to simulate a CGI call from within the program itself so that you can use a debugger to watch for problems that occur only with CGI input.
Setting Environment Variables
If your program uses any CGI environment variables, then you can modify the %ENV associative array (Such changes are temporary and only affect the program while it is running).
This allows you to enter several lines at the beginning of the program, with the help of which the environment variables that it uses are set. For example:
$ENV{'REMOTE_ADDR'} = '100.100.100.100';
$ENV{'REQUEST_METOD'} = 'GET';
$ENV{'QUERY STRING'} = 'name=Myname+ID=123456';Simulating form input
Another element that needs to be duplicated when simulating a CGI call is the form data that is passed into the program. If you use the GET method to transfer data to the form, then this is quite easy to do. The method passes the form data to the program in the QUERY_STRING environment variable, so you need to use something similar to the bottom two lines of the example above.
When using the POST method, the situation becomes only slightly more complicated. This method transfers form data to the program using STDIN and sets the amount of data transferred using the CONTENT_LENGTH environment variable. Therefore, the following CGI program can be used to collect data:
#!/usr/bin/perl
read(STDIN, $buffer, $ENV{'CONTENT__LENGTH'});
open (OUT,">path/to/form_data.txt");
print OUT $buffer;This program reads form data from STDIN and then writes it to a file. Then you should add the following lines to your CGI program:
$ENV{'REQUEST_METHOD'} = 'POST';
$ENV{'CONTENT_JLENGTH'} = -s '/path/to/form_data.txt';The CONTENT_LENGTH environment variable will contain information about the number of bytes contained in the file. Finally, you must call your program from the shell command line like this:
perl -d <ваш_скрипт>.cgi < /path/to/form_data.txtor
cat /path/to/form_data.txt | perl -d <ваш_скрипт>.cgiThese lines turn the POST request into a GET request and read the contents of the form data file into the QUERY_STRING environment variable.
How to see the invisible
It is very unpleasant that when logical errors are detected in a CGI program, a “500 Server Error” message is almost always generated, which will not say anything about what happened. If a program generates a "500" error and you don't know why, the easiest way to identify the problem is to force your browser to display an error message.
To do this, you need to put the following two lines at the beginning of the program (immediately after the line #!/usr/bin/perl:
$| = 1;
print “Content-type:text/plain\n\n”;
The first line instructs Perl to send all output directly to the browser without waiting for the buffer to fill. (Thanks to this, we see everything that the program outputs, and everything that Perl outputs while the program is running).
The second line tells the browser that everything your program outputs to STDOUT should be treated as plain text and displayed as such. If this line is present, then the next time you call the program you should see a message that causes it to issue a “500” error message.
You can then enter the program and fix the problem, or, if you want more, insert print statements into the program that will print diagnostic messages.
So, if the value of the $status variable should be equal to 1, and you suspect that it will be set incorrectly, insert the following line at the point where this variable should be equal to 1:
print “\$status = $status”;
The next time you call the program, you will see the value of the $status variable in your browser and will be able to determine whether this is the cause of the problem. (In essence, you perform the same actions in remote mode that you usually perform in the debugger).
For more complex errors, this method works quite slowly, but unlike other methods, it still works.
If your program performs multiple functions and the problem is related to only one of them, insert an HTTP header line at the beginning of the segment causing the problem. This will allow you to go through the normal segments as usual and set everything up to handle the failed segment.
