Полезная информация

Special Edition Using HTML 4

Previous chapterNext chapterContents

- 34 -
CGI Scripting

by Mark R. Brown and Melissa Niles

What Is the CGI?

In previous chapters you learned how to mark up content for your Web site by using the HTML standard. Now, we will begin our exploration of the CGI (Common Gateway Interface), which will greatly enhance the level of interactivity on your site. With the use of CGI scripts, you can make your Web presentations more responsive to your users' needs by allowing them to have a more powerful means of interaction with your material.

Here is the answer to the $100 question. What is the CGI anyway? Well, in order to answer that, you are going to need a little background information first.

Each time you sit down in your favorite and start surfing the WWW, you are a client from the Internet's point of view. Each time you click a link to request a new Web document, you are sending a request to the document's server. The server receives the request, then gets the document and sends it back to your browser for you to view.

The client/server relationship that is set up between your browser and a Web server works very well for serving up HTML and image files from the server's Web directories. Unfortunately, there is a large flaw with this simple system. The Web server is still not equipped to handle information from your favorite database program or from other applications that require more work than simply transmitting a static document.

One option the designers of the first Web server could have chosen was to build in an interface for each external application from which a client may want to get information. It is hard to imagine trying to program a server to interact with every known application and then trying to keep the server current on each new application as it is developed. Needless to say, it would be impossible. So they developed a better way.

These wise developers anticipated this problem and solved it by designing the Common Gateway Interface, or CGI. This gateway provides a common environment and a set of protocols for external applications to use while interfacing with the Web server. Thus, any application engineer (including yourself) can use the CGI to allow an application to interface with the server. This extends the range of functions the Web server has--including features provided by a potentially limitless number of external applications.

How the CGI Works

Now that you have read a little background, you should have a basic idea of what the CGI is and why it is needed. The next step in furthering your understanding of the CGI is to learn the basics of how it works. To help you achieve this goal, this material is broken down into the following sections:

The Process

The CGI is the common gateway or door that is used by the server to interface--or communicate--with applications other than the browser. Thus, CGI scripts act as a link between whatever application is needed and the server, while the server is responsible for receiving information from, and sending data back to, the browser.

NOTE: As a technical note, you should be aware that some people like to use the term program to refer to longer, usually compiled, code and applications written in languages like C and C++. When this is the case, the term script is then used to indicate shorter, noncompiled code written with languages like SH and PERL. However, for the purpose of this and the following chapter, the terms program and script will be used interchangeably as the divisions between them are being rapidly broken down.

For example, when you enter a search request at your favorite search engine, a request is made by the browser to the server to execute a CGI script. At this time, the browser passes the information that was contained in the online form, plus the current environment, to the server. From here, the server passes the information to the script. This script provides an interface with the database archive and finds the information that you have requested. Once this information is retrieved, the script processes the information entered by the visitor and sends the result to the server, which feeds it back to the visitor's browser as a list of matches to your query.


There are two popular methods of sending information to your scripts. The first is with the GET method. The GET method is the default method used. If no method is specified, then the default METHOD="GET" is assumed by the browser. If you are creating a form, then you can use this method by specifying this method when you insert the <FORM> tag within your document. An example would be


When using the GET method, the information entered by the visitor is sent to the server within the environment variable, QUERY_STRING. And as in the case of any environment variable, you are limited to 255 characters. This includes any space characters.

The other method commonly used is the method, POST. Using the method POST, information entered by the visitor is sent directly to your script through the server's STDOUT and your script's STDIN. The advantage of using the method POST, is that you aren't limited to 255 characters as you are when using the GET method. Here's an example of a form that uses the method POST:


ON THE WEB: There is a very nice online description of the CGI at The Common Gateway Interface, found at http://hoohoo.ncsa.uiuc.edu/cgi/.

Characteristics of the CGI

Another way of looking at the CGI is to see it as a socket that attaches an extra arm on your server. This new arm, the CGI script, adds new features and abilities to the server that it previously lacked.

The most common use for these new features is to give the server the ability to dynamically respond to the client. One of the most often seen examples of this is allowing the client to send a search query to a CGI script that then queries a database and returns a list of matching topics from the database. Besides information retrieval, another common reason for using CGI scripts is to customize the user interface on the Web site. This commonly takes the form of counters and animations.

TIP: If you see bin or cgi-bin in the path names of images or links, it is a good indication that the given effect was produced by a CGI script.

As you read earlier, there are two basic methods of sending information to your script. Those methods mentioned were the GET and the POST methods. Depending on which method is used, your script will parse the information differently. While this difference is small, it can create havoc if your script doesn't parse the information coming from the visitor correctly. Listing 34.1 checks which method is being used and parses the information coming from the visitor based on the method used.

Listing 34.1  PERL Script that Parses Information Depending on Method

#! /usr/bin/perl
read(STDIN, $buffer, $ENV{`CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
@pairs = split(/&/, $ENV{`QUERY_STRING'});
foreach $pair (@pairs)
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;

Using this basic header to all your CGI scripts written in PERL will save you a lot of headaches. The information is parsed and split automatically, with each item sent by the visitor placed into an array called @contents. Each individual item in the array can be called by using $contents{`name'}, where the name is the name assigned to the variable when you created your form.

The MIME Content-Type Output Header

It won't be long into your CGI programming career when you will want to write a script that sends information to the server for it to process. Each file that is sent to the server must contain an output header. This header contains the information the server and other applications need to transmit and handle the file properly.

The use of output headers in CGI scripts is an expansion of a system of protocols called MIME (Multipurpose Internet Mail Extensions). Its use for e-mail began in 1992 when the Network Working Group published RFC (Request For Comments) 1341, which defined this new type of e-mail system. This system greatly expanded the ability of Internet e-mail to send and receive various nontext file formats.

NOTE: Since the release of RFC 1341, a series of improvements has been made to the MIME conventions. You can find some additional information about this by looking at RFC 1521 and RFC 1522. A list of all the RFC documents can be found online at http://ds0.internic.net/rfc/. These documents contain a lot of useful information published by the Network Working Group relating to the function and structure of the Internet backbone.

Each time you, as a client, send a request to the server, it is sent in the form of a MIME message with a specially formatted header. Most of the information in the header is part of the client's protocol for interfacing with the browser. This includes the request method, a URI (Universal Resource Identifier), the protocol version, and then a MIME message. The server then responds to this request with its own message, which usually includes the server's protocol version, a status code, and a different MIME message.

The bulk of this client/server communication process is handled automatically by the WWW client application--usually your Web browser--and the server. This makes it easier for everyone, since you don't have to know how to format each message in order to access the server and get information. You just need a WWW client. However, to write your own CGI scripts, you will need to know how to format the content-type line of the MIME header in order for the server to know what type of document your script is sending. Also, you will need to know how to access the server's environment variables so you can use that information in your CGI scripts. In the following sections, you will learn everything necessary to accomplish both of these tasks.

NOTE: If it won't be long into your CGI programming career when you decide to write your own WWW client, then you need to understand the client/server communication process before you can begin. A good place to start your search for more information about this is the World Wide Web Consortium (W3C) Reference Library at http://www.w3.org/pub/WWW/Library/.

Using a Content-Type Output Header

Each document that is sent via a CGI script to the server, whether it was created on the fly or is simply being opened by the script, must contain a content-type output header as the first part of the document so the server can process it accordingly. In Table 34.1 you see examples of a few of the more commonly used MIME content-types and their associated extensions.

Table 34.1  Examples of MIME Types and Extensions

Content-Type Extensions
application/octet-stream bin exe
text/html html htm
text/plain txt
text/richtext rtx
video/mpeg mpeg mpg mpe
video/quicktime qt mov
video/x-msvideo avi

To help you better understand how to properly use content-types within a CGI script, let's work through an example. Suppose you have decided to write a CGI script that will display a GIF image each time it is executed by a browser.

The first line of code you need is a special comment that contains the path to the scripting language that you are using to write the program. In this case it is PERL. The comment symbol (#) must be followed by an exclamation point (!) then the path. This special combination of (#!) on the first line of the file is the standard format for letting the server know which interpreter to use to execute the script. The reason this special comment is used is that while UNIX servers use this line of code to locate the script's interpreter, other types of server systems have alternate methods of specifying the interpreter's location. However, since this line of code starts with a (#) symbol, it is still a valid PERL comment and does not cause problems on nonUNIX servers.


The next line you will need simply sets the variable $gif to the full path name of the image you want to display.

$gif = "/file/path/your.gif";

TIP: You should double check to make sure you include the correct path name to your language's interpreter.

Now, it is time to let the server know that it will be receiving an image file from this script to display on the client's browser. This is done by using the MIME content-type line. The print statement prints the information between the quotation marks to the server. Each set of \n characters that you see on this line adds a carriage return with a line feed. This gives you the required blank line that must occur after the content-type information. A blank line lets the server know where the MIME header stops and where the body of information, in this case the GIF, starts.

print "Content-type: image/gif\n\n";

The next line creates a file handle named IMAGE that forms a link from this script to the file contained in the variable $gif, which you set earlier.


Now, you create a loop that sends the entire contents of the gif to the server as the body of the MIME message you began with the content-type line.

while(<IMAGE>) { print $_; }

To avoid being sloppy, close the file handle to the gif now that you are done sending the image.


Finally, let the PERL interpreter know that the CGI script is finished running and can be stopped.


This type of script can be modified into something a little more useful. For example, you could turn it into a random image viewer. Each time someone clicks the link to the script, it executes and feeds a random GIF image to the client's browser.

Environment Variables

Hopefully, you now have a little better understanding of what is involved as the client and server communicate with each other. Along with the information discussed earlier, a host of environment variables are sent during the client/server communications. Although each server can have its own set of environment variables, for the most part, they are all subsets of a large set of standard variables described by the Internet community to help promote uniform standards (see Figure 34.1).

If you have bin access on a UNIX server, then you can use the following script to easily determine which environment variables your server supports. In addition, this script should also work on other server types such as Microsoft Windows NT server if you properly configure the server to recognize and execute PERL scripts.

Once again, this is the magic line that lets the server know which type of CGI script this is so it can launch the appropriate interpreter.


This next line, as was described, is the MIME output header that lets the server know to expect an HTML document to follow.

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

Now that the server is expecting to receive an HTML document, send it a list of each environment variable's name and current value by using a foreach loop.

foreach $key (keys(%ENV)){
print "\$ENV{$key} = \"$ENV{$key}\"<br>\n";

Finally, you need to tell the interpreter that the script is finished.


FIG. 34.1
Using the CGI script environment.pl from a browser generates a screen similar to this one.

TIP: If the browser you use doesn't support an environment variable, the value of the variable is set to null and is left empty.

As you can see from the example, most of the variables contain protocol version information and location information such as the client's IP address and the server's domain. However, if you are creative, you can put some of these variables to good use in your CGI scripts.

One good example is the use of the environment variable HTTP_USER_AGENT. This contains the name and version number of the client application, which is usually a Web browser. As you can see from Figure 34.1, the Netscape 4.0 browser used when running this script has a HTTP_USER_AGENT value of Mozilla/4.0b1 (Win95; I).

Once you know what the values are for various browsers, it is possible to write a CGI script to serve different Web documents based on browser type. Thus, a text-only browser might receive a text version of your Web page, while image-capable browsers will receive the full version.

Can You Write CGI Scripts?

Before you can get started writing your own CGI scripts, you need to find out if your server is specially configured to allow you to use them. The best thing to do is contact your system administrator and find out if you are allowed to run CGI scripts on the server. If you can, you also need to ask what you need to do to use them and where you should put the scripts once they are written.

In some cases, system administrators do not allow clients to use CGI scripts because they feel they cannot afford the added security risks. In that case, you will have to find another means of making your site more interactive.

If you find that you can use CGI scripts and are using a UNIX server, then you will probably have to put your scripts into a specially configured directory, which is usually called cgibin or cgi-bin. If you are using Microsoft's Internet Server, then you will probably put your CGI programs in a directory called Scripts. This allows the system administrator to configure the server to recognize that the files placed in that directory are executable. If you are using a NCSA version of HTTPD on a UNIX system, then this is done by adding a ScriptAlias line to the conf/srm.conf file on the server.

NOTE: It is important to remember that although CGI scripts are not necessarily complex, you need to have some basic understanding of the programming language you wish to use and the server you plan to run the scripts on. Poorly written scripts can easily become more trouble than they are worth. For example, you could delete entire directories of information or shut down your server if your script were to start launching new processes in a geometric fashion.
Before starting down the road to becoming a CGI scripter, you should do the following:

Which Language Should You Use?

Now that you know what a CGI script is, how it works, and what it can do, the next thing you need to consider is which language you should use. You can write a CGI script in almost any language. So, if you can program in a language already, there is a good chance you can use it to write your scripts. This is usually the best way to start learning how to write CGI scripts, since you are already familiar with the basic syntax of the language. However, you still need to know which languages your Web server is configured to support.

UNIX-based Apache and CERN Web servers are the most common. These platforms are easily configured to support most of the major scripting languages, including C, C++, PERL, and the basic shell scripting languages like SH. On the other hand, if your Web server is using the Mac server, then you might be limited to using AppleScript as your scripting language. Likewise, if you are using a Windows NT server, you might need to use Visual Basic as your scripting language. However, it is possible to configure both these systems to support other scripting languages like C and PERL, or even Pascal.

NOTE: If you are interested in finding out which scripting languages your server is configured to support, you should ask your system administrator to give you a listing of what is available on your server.
Also, if you have access to a UNIX-based server and can log into a shell account, then you can find out which languages your system supports by using the UNIX command "which."

If you are using the SH shell, you should see the following:
$ which sh
$ which perl5

Many scripting languages are freely distributed and fairly easy for an experienced administrator to install. As a last resort, you can always request that a new language be considered for addition to your local system.

If you are lucky, you may find that your server is already configured to support several CGI scripting languages. In this case, you just need to compare the strengths and weaknesses of each language you have available with the programming tasks you anticipate writing. Once you do this, you should have a good idea of which programming language is best suited to your needs.

Common CGI Scripting Languages

When it comes to the CGI, anything goes. Of the vast numbers of programming languages out there, many more than you could possibly learn in a lifetime, most can work with the CGI. So, you will have to spend a little time sifting through the long list to find the one that will work best for you. For some, which language used will completely depend on what you are most familiar with, or what languages are available for use.

Even though there are a lot of different languages available, they tend to fall into several categories based on the way they are processed--compiled, interpreted, and compiled/interpreted--and on the logic behind how the source is written--procedural and object-oriented. A listing of the more prevalent languages is found in Table 34.2.

Table 34.2  Various Languages Used to Create CGI Applications

Language System Type
Shell UNIX Interpreted (Command Line Interface)
PERL UNIX, Windows, InterpretedMacintosh, Amiga
C UNIX, Windows Compiled
C++ UNIX, Windows Compiled
Visual Basic Windows Compiled
AppleScript Macintosh Interpreted
TCL UNIX Interpreted
REXX (AREXX) OS2, Amiga Interpreted (some versions can be compiled)

Creating CGI Scripts

Once you have decided on a language to use, you find that various applications can be developed using the CGI. By far, e-mail, guestbook, redirection, counters, and advertisement banners are the most widely used scripts found to add interactivity to your Web pages, or to simply spice up a Web page. These scripts are covered in this section in more detail.

An E-Mail Script

E-mail scripts are just about the oldest and most used scripts in use on the World Wide Web. Interfacing the Web with e-mail just seems like a good idea. By doing so, you can give someone visiting your site the ability to communicate with you whether or not she has an e-mail account herself. All their browser needs to be able to do is allow the visitor to use forms.

Another benefit of an e-mail script is that you can create scripts that notify you if, let's say, a visitor enters information into a guestbook. You can also provide online ordering. A visitor selects items to be purchased. When they are done, the items requested can be e-mailed to you, or someone in your company, for processing.

Listing 34.2 is a form a user can fill out. The fields entered are name, an e-mail address, a subject line, and comments. Just about the same items most people fill out when sending e-mail via conventional means.

Listing 34.2  mail.html--A Simple Form that Allows the Visitor to Send E-Mail

<H1>EMAIL ME!</H1>
Please fill out the form to send me email!<P>
Realname:<INPUT TYPE="TEXT" NAME="realname"><br>
Email address:<INPUT TYPE="TEXT" NAME="email"><br>
Subject: <SELECT NAME="subject">
<OPTION>Reply please
Enter your comments:<br>
<TEXTAREA NAME=comments ROWS=10 COLS=60>

Once the form is filled out by the visitor, the information entered is then sent to the server, which in turns sends that information to the CGI script indicated by using the ACTION attribute. In this case, the information entered by the visitor is sent to the script mail.pl.

If you take a look at Listing 34.3, you can see the full version of our mail.pl script. The first line tells the system this is a PERL script, and the full path is given to PERL, which is the program that will interpret the script.

Next, two variables are set. The first variable is the path to the sendmail program, which will actually send the e-mail to its destination. The second variable is the recipient, that is, the e-mail address that will receive the e-mail. We define this here so that the person visiting the site can't save a copy of our form and change the e-mail address to which this message is being sent.

Next, the script breaks the input stream coming from the server and places the value of each entry into the array named contents. This allows you to easily manipulate the information entered by the visitor.

Lastly, the e-mail is sent, and a Thank You page is displayed back to the visitor, letting him know that his comments were successfully sent.

Listing 34.3  mail.pl--The Visitor's Comments Are Processed and Sent to the Recipient

$mailprog = "/usr/lib/sendmail";
$recipient = "user\@foo.bar.com";
read(STDIN, $buffer, $ENV{`CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
# Open The Mail
open(MAIL, "|$mailprog -t") || die "Can't open $mailprog!\n";
print MAIL "To: $recipient\n";
print MAIL "From: $contents{`email'} <$contents'realname'}>\n";
print MAIL "Subject: $contents{`subject'}\n\n";
print MAIL "$contents{`comments'}\n\n";
print <<"HTML";
<HEAD><TITLE>Thank you!</TITLE></HEAD>
<H1>Thank you!</H1>
Thank you for your comments!
<A HREF="http://www.selah.net/cgi.html">[Return to the main page]</A>

By convention, one of the most important parts of a CGI script is to return something to the visitor. In the above example, you simply thanked the visitor for his comments. To send something back to the visitor is one of the basic rules of CGI scripting. Doing so tells the visitor that the information they entered was processed correctly, or at times the information returned will be results to a query they entered. Using search engines is a good example of returning information to the visitor. If a header is sent to the visitor without any content, then your browser will simply sit there or, in the case of Netscape, a dialog box will appear stating that the document contains no data.

A Simple Guestbook Script

Guestbook scripts are another popular script. I'm sure you have seen some sort of guestbook script on someone's personal home page, and even on commercial sites.

Guestbooks scripts allow the visitor to not only interact with you but also with other individuals that visit your site. By using a guestbook script, you just expanded upon how those visiting your site can interact. Guestbook scripts are used to allow the visitor to simply say "Hello" or to allow visitors to ask questions, hoping that someone visiting the site at a later date can answer that question.

The guestbook script, written by Jeffry Dwight, can be found on the CD-ROM named SGB1.EXE and contains both the HTML code, initially provided to allow visitors to enter comments, and the guestbook itself, allowing the visitor to read what others have entered. This script was written in C to run on Windows NT and Windows 95 (tested with WebSite and MS's Personal Web Server on Windows 95). The compiled binary has been provided, as well as the source code and makefile.

The script is fairly simple and heavily commented with explanations on how the CGI script works. If you take a look at Figure 34.2, you can get an idea of how it works as it stands. If you have a C compiler (a must if you are going to create CGI scripts in C), you can edit the script so the script is customized to the look and feel of your specific site.

FIG. 34.2
SGB1 is a simple CGI script written in C that allows your visitors to communicate with each other.

ON THE WEB: For those of you who would like to use a guestbook script that was written in PERL, Matt Wright provides a nice guestbook script that can be found at http://www.worldwidemart.com/scripts/guestbook.shtml.

A Redirection Script

Another commonly requested script is the redirection script. A redirection script allows the visitor to select an item from a list and automatically send it to the site chosen.

Okay, so this is basically how links on Web pages work in the first place. Very true, but what you might, or might not, be aware of is you can log only where a visitor came from; the server doesn't have the capability to log where you go to. Redirection scripts solve this problem.

No longer are advertisers interested solely in how often their banner is displayed to the public. Advertisers want to know if their banner is having an effect on those visiting your site. Redirection scripts help you log how many times a link has been clicked.

The script redirect.pl, shown in Listing 34.4, performs this function by taking the URL that the visitor requested and logging it, and then by using the Location header, they are redirected to the site in question.

First, when the script is called, three buttons are provided for the visitor to click. Once clicked, the script logs the request to the log file specified in the variable logfile. In this instance, the log file is called redirect.log. The log file contains the date and which place the visitor wished to visit.

Listing 34.4  redirect.pl--A Simple Script that Logs the URL the Visitor Clicks

# Copyright 1996, Robert Niles
$logfile = "redirect.log";
read(STDIN, $buffer, $ENV{`CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
chop($date = `date`);
&logit if $contents{`location'};
print "Content-type: text/html\n\n";
print <<"HTML";
<form action="/cgi-bin/redirect.pl" method="POST">
<input type="submit" name="location" value="Infoseek"><br>
<input type="submit" name="location" value="AltaVista"><br>
<input type="submit" name="location" value="WebCrawler"><br>
sub logit {
if ($contents{`location'} eq "Infoseek")
$location = "http://www.infoseek.com";
if ($contents{`location'} eq "AltaVista")
$location = "http://www.altavista.com";
if ($contents{`location'} eq "WebCrawler")
$location = "http://www.webcrawler.com";
open(LOG, ">>$logfile");
print LOG "$date User clicked on: $contents{`location'}\n";
print "Location: $location\n\n";

Simple Count

Counters allow you to find out how many people have visited your page. A page with a low count could tell you the page might not be worth keeping. A page with a high count might indicate that it could use some expansion.

Counters are on just about every other page on the Net. In some instances they have been used as a way of bragging, "My dad is tougher than your dad." Some counters seem quite irritating in that they are heavily loaded with graphic images and seem to take forever just to display. Others, though, are simple counters created to inform not only the administrator of the site of how busy a site might be but also those visiting your site as to how often your page is visited--a very handy tool if you are attempting to attract potential advertisers.

The count.pl script shown in Listing 34.5 demonstrates how you can keep track of how often your site is being visited. The script is simple and displays only a small line with the number times your page has been accessed. The script can also be configured so that the access count is not displayed to those visiting your site. This allows you to know what your "hit" rate is without divulging the count to everyone visiting your page.

The script is accessed by using Server Side Includes (SSI). By using SSI to execute a script, you don't have to access the script directly, or with a form. What SSI does is return the result of a script directly within the HTML document that called the script.

Whether you can use SSI depends on your Web administrator. Some sites, for security reasons, do not allow normal users to utilize SSI. Also, some of the older Web servers don't have the ability to use SSI. If in doubt, check with your administrator.

How SSI is used varies, but with count.pl you want to use the SSI command,

<!--#exec cgi="count.pl"-->

wherever you want the page to display the count. For example, if you would like to have the access count displayed at the bottom of your page, you would have an HTML document that looks like:

Hello visitor!<p>
You are visitor number: <!--#exec cgi="count.pl"-->

The count.pl script can also be used to keep track of several pages by using one script. Just make sure the path is pointing to where the script resides. In this example, the script resides in the same directory in which the script was called. If the script resides in the /cgi-bin/ directory, then the SSI command will need to reflect this.

Also, ensure that the countfile exists. This script is quite simple, and although it functions well, it doesn't create the countfile automatically.

Last, not all versions of PERL use the flock() function. If your version of PERL doesn't support flock(), then you will want to rewrite the script to use fcntl().

Listing 34.5  count.pl--A Simple Hit Counter

# simplecount 1.0
# count.pl
$uri = $ENV{`DOCUMENT_URI'};
$countfile = "count";
print "Content-type: text/html\n\n";
open(COUNT, "+<$countfile") || do{
print "Can't open count file";
die; };
flock(COUNT, 2);
while (<COUNT>) {
($file, $count) = split(/:/, $_);
$counts{$file} = $count;
seek(COUNT, 0, 0);
foreach $file (keys %counts) {
print COUNT $file, ":", $counts{$file}, "\n";
flock(COUNT, 8);
print $counts{$uri};

An Advertisement Banner

Using advertisement banners like those seen on the more popular Web pages have been mentioned in the last two sections. Advertisement banners allow a company to place a small ad on your page that is, usually, linked to its site. The nice thing about allowing advertisement banners is that companies are quite willing to pay large sums of money for you to display their banner--especially if you have a site that is heavily accessed. In fact, the busier your site, the more money you can make with advertising!

The script randpic.pl randomly picks and displays a banner like the banner shown in Figure 34.3. Each banner displayed contains the path to the banner image, the URL visitors will be sent to if they click the banner, a short line used as the graphic alternative, and a line in which a short slogan is displayed.

FIG. 34.3
Randpic.pl is a simple script that randomly picks and displays an advertisement on your page.

If you take a look at Listing 34.6, there are four arrays used to provide information about each banner. The first section of the script defines each array. The next section selects a random number using the current time as the seed. Once done, HTML is created, which is placed in the HTML document calling the randpic.pl script.

Listing 34.6  randpic.pl-- Place Advertisement Banners on Your Web Pages

# randpic.pl
@pics= ("pics/cgiad.gif",
@url= ("www.selah.net/rate.html",
@alt= ("The CGI Collection",
"InCommand Internet Marketing");
@comment= ("Advertise on the Web with The CGI Collection",
"Providing Intranet\/Internet Applications for Businesses");
# Now we pick a random number and assign it to $picnum
srand(time ^ $$);
$picnum = rand(@pics);
# Now we display it. I've used tables here to format the output nicely.
print "Content-type: text/html\n\n";
print "<table border=0>";
print "<tr><td align=center>";
print "<a href=\"http://$url[$picnum]\">";
print "<IMG SRC=\"$pics[$picnum]\" alt=\"$alt[$picnum]\" border=0>";
print "</A>";
print "</td></tr>";
print "<tr><td align=center>";
print "<a href=\"http://$url[$picnum]\">$comment[$picnum]</a>";
print "</td></tr>";
print "</table>";

Just like the count.pl script discussed in the previous section, this script requires the use of Server Side Includes. In this example, you would place the line

<!--#exec cgi="randpic.pl"-->

in your HTML document where you would like the banner to be displayed.

Now that you have been introduced to CGI scripting, it's time for you to write your own scripts (or simply edit the scripts provided to suit your needs), which can be used to spice up your pages and provide a little more interactivity between you and those visiting your site. After all, allowing those visiting your site to interact with you, and others, is the main reason why the World Wide Web has become so popular.

ON THE WEB: If you would like more information on CGI scripts, and various CGI scripts available for use, visit http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI___Common_Gateway_Interface/.

Previous chapterNext chapterContents

© Copyright, Macmillan Computer Publishing. All rights reserved.