Q&A
| Q | How do I test the program in Exercise 3.2 (Listing 3.9)? |
| A | Using the Perl debugger is probably the easiest method to test this program. When you use the debugger, you can set the variables in the program that control the condition expression. To test this program using the debugger, let lines 5-7 execute and then change the variables to execute the different conditional expressions. Start by running the program through without any changes, and confirm that it works without changes. Next, start modifying the $hour variable so that it returns True for the different condition expressions. Unless it’s Christmas eve or Christmas day, change the $month to 11 and $day_of_month to 25 to test the Merry Christmas block of statements. If it is Christmas, give it a rest and go play! |
| Q | Why don’t the following three commands work? Error 1: <!--#flastmod file="../cgi-bin/cgi-lib.pl" --> |
| A | This file command tells the server to use a relative pathname to find the file you want to get the last modification date on. So if you are one directory down from the cgi-bin directory, this should work. But it doesn’t. This type of pathname is valid from within your CGI programs and from the command line. If you do an ls -lat ../cgi-bin/cgi-lib.plyou probably will get a valid response. In this case, however, the file command argument is valid only with the current directory and subdirectories. Use the virtual command to find the cgi-bin directory. Assuming that the cgi-bin directory is just below the server root, try this command: <!--#flastmod virtual="/cgi-bin/cgi-lib.pl" -->Error 2: <--#exec cmd = "pwd" --> I would expect you to suspect the spaces around the equal sign (=) in this command, but that’s not the problem. The opening HTML tag (<--) is missing the exclamation point (!). The command will work if you type it as the following: <!--#exec cmd = "pwd" --> Error 3: This is an example of spacing problems, and it is probably one of the most common mistakes made when trying to get SSI commands to work. You must include at least one space before the closing HTML tag (-->). The command will work if you type it as the following: |
| Q | Why don’t I see an error message from my SSI command? |
| A | What is the file extension of the file that your SSI command is part of? I’ll bet you it’s not .shtml. It’s very easy to forget that the server ignores all SSI commands not in the correct file type. And because the SSI command is enclosed in a valid HTML Comment tag (<-- Comment -->), the server sends your SSI command to the browser without trying to execute it. The browser reads the HTML, sees the HTML Comment field, and ignores the line altogether. |
| Q | Why can’t I execute the system commands I can from the command line? |
| A | When your SSI exec command is executed by the server, your user group probably is set to a restricted access user group like Nobody. Just as you have limited privileges to move around your server, when someone accesses your Web page, the same thing happens. The Web server environment usually allows your Web pages to be accessed under the process group Nobody. The process group Nobody may have fewer privileges than you do as a normal user. If some of the system commands you are using as SSI commands work from the command line, but not within your SSI exec command, first check for all the usual SSI errors, and then e-mail your System Administrator to see whether those commands are enabled for the user group Nobody. You can’t test for this from the command line, because you will not be executing under the restricted Nobody process name. |
