Chapter Thirteen - CGI Scripts

CGI-bin Applications
Where to Put CGI-bin Scripts
Paths to Date, Mail, Perl, etc.
Setting Permissions
Quick guidelines on using SSI's
Troubleshooting CGI-bin Problems
Server Side Includes (SSI)
 

CGI-bin Applications

CGI stands for "Common Gateway Interface," a fancy name meaning computer programs running on the web server that can be invoked from a www page at the browser. The "bin" part alludes to the binary executables that result from compiled or assembled programs. It is a bit misleading because cgi's can also be Unix shell scripts or interpreted languages like Perl. CGI scripts need to be saved in ASCII format and uploaded to your server's cgi-bin in ASCII or text format. This is very importa nt. 

We do not provide Technical Support for CGI scripts. So if you are not already familiar with CGI scripting, you may want to read a book on the subject or find places on the Internet with CGI scripting information. There are many good resources for CGI scr ipts found on the web. The scripts at Matt's Script Archive found at http://www.worldwidemart.com/scripts/ are very good. You'll find many scripts free of charge and with detailed configuration information. Another excellent resource is The CGI Resource I ndex found at http://www.cgi-resources.com/ -- if you are not an expert, look for scripts that are very well documented and come with step-by-step instructions. 

Back to the top
 

Where to Put CGI-bin Scripts

Put your cgi-bin scripts in the www subdirectory named "cgi-bin". 

Back to the top
 

Paths to Date, Mail, Perl, etc. 

Here are your paths to the common server resources that CGI scripts often require: 

Sendmail: /usr/sbin/sendmail
Date: /bin/date
Perl5: /usr/bin/perl
Serverpath: /home/username/domain-www/cgi-bin
Back to the top
 

Setting Permissions

The following is a simple explanation of file permissions in Unix. To list the access permissions of a file or directory, telnet to your server, then: 

cd directoryname 

to change the directory until you are either in the directory above the file you are interested in, or above the directory you are checking. 

Type: ls -l filename 

and you will see what the current permission settings are for that file, along with a bunch of other stuff. 

Examples of using chmod: 
 

People: u = the file's user (you)  g = the file's group o = others a = the user, the group, and others

Permissions: r = read access x = execute access w = write access

To change permissions for a file named filename.cgi, you need to chmod the file (change mode). For example, when you type this: 

chmod u=rwx,g=rx,o=rx filename.cgi 

by typing this you have given: 

read, execute, and write access to the user (that's you) 
read and execute access to the group and; 
read and execute access to others

Some scripts will tell you to chmod 775 (for example). Doing the above is the same thing as typing chmod 775. You can use either method with our Unix servers. Let me explain: 

When using the numeric system, the code for permissions is as follows: 

r = 4 w = 2 x = 1 rwx = 7

The first 7 of our chmod775 tells Unix to change the user's permissions to rxw (because r=4 + w=2 + x=1 adds up to 7. The second 7 applies to the group, and the last number 5, refers to others (4+1=5). 

When doing an ls -l on the file, telnet always shows the permissions this way: 

-rwxr-xr-x

Ignore the first dash, then break up the above into three groups of letters. If there's a dash where a letter should be, it means that there is no permission for those people. 

Remember: the first 3 apply to user, the second 3 apply to group, and the third 3 apply to others. 

Some FTP clients support changing permissions in a more graphical way. If you have Fetch for the Mac, you have an easy way to change permissions. Go to the file you want to change the permissions on, and highlight it. Under the Remote menu, select Change Permissions. A window will pop up showing the current permissions for the file you had highlighted. Click on the boxes to change permissions as needed. 

WS_FTP accomplishes the same task as above. Just highlight the file you want to check, and right-click on it. A menu will pop up, then select CHMOD. 

Back to the top
 

Troubleshooting CGI-bin Problems

Below are solutions to some of the more common CGI script problems, in question and answer format. You will find a list of proper permission settings for the scripts we provide at the end. 

When I activate my CGI program, I get back a page that says "Internal Server Error. The server encountered an internal error or mis-configuration and was unable to complete your request." 

This is generally caused by a problem within the script. Log in via Telnet and test your script in local mode to get a better idea of what the problem is. To do this, go into the directory in which your script is located, then execute the script. To execu te the script, you can do it by two ways: 

1) Type "perl myscript.pl" (Perl being the language interpreter in this case). 
2) Or simply type "myscript.pl" alone, that will work if the first line is well written to indicate the location of Perl. 

The first one is useful to see if there's any error IN your script. The second one is useful to test if your "calling line" (the first line of the script) is okay, i.e. if you entered the right location of Perl. 

I am being told "File Not Found," or "No Such File or Directory."

Upload your Perl or CGI script in ASCII mode, not binary mode. 

When I test my Perl script in local mode (by Telnet), I have the following error: "Literal @domain now requires a back slash at myscript.pl line 3, within string. Execution of myscript.pl aborted due to compilation errors." 

This is caused by a misinterpretation by Perl. You see, the "@" sign has a special meaning in Perl; it identifies an array (a table of elements). Since it cannot find the array named domain, it generates an error. You should place a back slash ( \) before the "@" symbol to tell Perl to see it as a regular symbol, as in an email address. 

I am getting the message "POST not implemented." 

You are probably using the wrong reference for cgiemail. Use the reference /cgi-bin/cgiemail/mail.txt. Another possibility is that you are pointing to a cgi-bin script that you have not put in your cgi-bin directory. In general, this message really means that the web server is not recognizing the cgi-bin script you are calling as a program. It thinks it is a regular text file. 

It's saying I don't have permission to access /

This error message means that you are missing your index.htm file. Note that files that start with a "." are hidden files. To see them, type ls -al. If you wish to FTP this file in, go to the home/yourdomain directory. 

Back to the top
 

Server Side Includes (SSI)
 

What is SSI?

Used properly, the SSI can help make your pages more responsive and can even help make maintaining your site an easier task. 

Put simply, SSI is sort of like using your HTML server as a cut and paste editor. Here is basically what happens when your server handles a request for an SSI document. If you use SSI, you must rename the page so that it ends in .shtml so that the server knows to parse the page for SSI commands. 

• The server reads the document and parses (techie word for chops up and looks for special instructions) it for directives. (another techie word for directions!)
• Follows the instructions that it finds and merges their results into creating a finished document.
• The document is then sent to the client browser. 

How to Use SSI

The syntax ofr an SSI include is as follows: 

<!--#include file="mailform1.txt" -->

Where mailform1.txt is the path to the file that you want to be included. For instance if you have a file called file.shtml and you include the SSI 

<!--#include file="mailform1.txt" -->

The contents of mailform1.txt will be displayed in file.shtml. 

There are many good tutorials in SSI available on the Web. Here are a few that we recommend: 

http://bignosebird.com/ssi.shtml

http://usats.com/learn/ssi.shtml

http://www.ora.com/info/cgi/ch05.html

Back to the top