Master just a few basic concepts, know where to get the information you need, and you can configure these very useful scripts for your business web site

Often, business owners feel they already have too many other things to do to have to learn about CGI scripts. Besides, if they’re honest, they are more than a little intimidated by the coding. Let’s face it, if you don’t have a background in programming, even HTML can look pretty incomprehensible the first time you see the naked code. When it comes to the lovely world of CGI — programs, or “scripts”, written in Perl, C++, Java, etc. — even the bravest often quail.

CGI stands for Common Gateway Interface. According to a definition I found at the Virtualville Public Library (https://www.virtualville.com), “The Common Gateway Interface, or CGI, permits interactivity between a client and a host operating system through the World Wide Web via the Hyper Text Transfer Protocol (HTTP).”

Or, in English, it lets Joe Blow on his home office personal computer access a program on your server via your web page, and have it execute a task for him. If, for example, he wanted to post to your message board, your CGI script will take the data he inputs (his post and any other information required), process it in whatever way the script tells it to, and produce the requested output — a post on a message board.

Fortunately for you, you don’t really need to know how to get it to do all that. There are plenty of places around the Web that provide CGI script resources. You can find counters, search tools, discussion forums and message boards, email forms processing programs, banner rotation programs and plenty more — and those are just the kinds of scripts that are still usually free. There are also fancier items like affiliate program scripts, shopping carts scripts, database scripts and so on.

These scripts are a bit like home entertainment systems. The fancier it is, and the more buttons it has, the more things on it that might possibly break. My advice is to stick with the simple stuff for your first forays into the wonderful world of CGI.

Now, there are going to be a few basic things you will need to know in order to install, say, a guest book script onto your web site. First, you need to be able to upload directly to your server. Some scripts assume that you’ll be using Telnet to do this, but I personally prefer WS-FTP Pro. It’s a nifty little program that not only helps you ftp into your server space (“ftp” stands for file transfer protocol, in case you were wondering), it also helps you do other important things.

So here are the basics for configuring a perl script, any perl script. (Although I should just mention that everything in this tutorial is specific to Unix servers. I have no experience with Windows NT servers, and no intention of ever using one. However, most scripts that can be used on an NT server come with NT-specific instructions.)

Paths to perl. This will be the first line in any perl script and it absolutely has to be there. It simply tells the server that the program is written in perl rather than, as Webmonkey’s Colin Ferm once put it, “Russian on acid”. It also tells the server where, inside its own innards, the perl compiler is located. It will look something like this:

#!/usr/local/bin/perl

You need to reference the compiler because it is a kind of translator; the server won’t know how to understand perl if it doesn’t have this internal dictionary. In any event, your hosting company should have this information in the documentation on your control panel. If not, call tech support.

Your system paths

There will probably be a number of places in the installation instructions in which you are asked to provide the system path to something or other. This is not the URL to that particular thing. Under most circumstances, the program is not interested in the HTML page that the URL references; the program is really interested in the directory structure it has to navigate.

That’s the thing about configuring any CGI script. All you’re really doing is telling the program where to find everything it needs to do what you want it to do. The only other thing you need to tell it is how the program’s output is supposed to look ?? but we’ll get to that in a few minutes.

System paths start with a slash (“/”). So, let’s say that your guest book configuration file wants the system path to the location of the script. That might look like this:

/usr/www/[your username]/cgi-bin/guestbook/

This indicates to the program that it is located in your cgi-bin, in a subdirectory called “guestbook”. Some programs want the trailing slash, some of them will vehemently tell you not to include a trailing slash. Follow directions.

This is another piece of information that should be available somewhere in your control panel. But, in case you can’t find it, another place to look is in your WS FTP Pro. When you log in to your server space with this program, it will show you the system path right at the top of the right side of the window, labeled “Remote Site” (as illustrated in the screen shot below).

If your program is designed to send you or anybody else email when it is being used, then it is probably also going to want to know where to find your server’s Sendmail program. Usually, the path to Sendmail looks like this:

/usr/bin/Sendmail

But on my server, for example, it is just a tiny bit different (/usr/sbin/Sendmail). So, if you want that email, make sure you’ve got this right.

Setting Permissions

Another thing you’ll have to do, and do right, if you want your scripts to work is to set the correct permissions on the relevant files. You’ll be told which permissions need to be set for which files and directories when you install. Sometimes, the program installation instructions will give you the permission requirements like this:

chmod rwxr_xr_x

which, you’ll have to admit, looks pretty incomprehensible. Other scripts will tell you to CHMOD to 755 or 644 or whatever. Either way, you will have no idea what they’re talking about.

The permissions are set up in a sort of grid. You give permissions for owner, group, and “other”, while the permissions you give are read, write and/or execute. It is possible to set your permissions using Telnet, and some hosting companies even have their browser-based control panels set up in such a way that you can do it from there.

I have found that the absolutely easiest way to do this is to use WS FTP Pro. If you go to the remote site listing, highlight any file or directory and right-click on it, one of the choices you’ll have will be “chmod (Unix).” When you select it, you are confronted with a small window that will give you the option of either using the checkboxes to check on read, write and execute for each column, or to insert the numberical value.

The other items involved in configuration for most of the simpler scripts are things you already know if you are familiar with HTML. There may be instances where you’ll need to create header and footer text files for the script to use in order to make the pages it produces conform to the look and feel of the rest of your site. Or, it may ask you for things like those six digit RGB color codes for background, font colors and so on. Nothing to tax the technically challenged there.

So, once you can wrap your mind around those items that you don’t normally have to deal with, like system paths and setting permissions, you can start to experiment. CGI scripts are great, because they can give your site a degree of technical sophistication that makes your business look as if it had the resources to pay programmers and things. That can help establish your credibility and, because CGI is primarily used for interactive features, it will also help you to enhance your relationships with your customers.

And it’s really not all that hard. Try it.

Copyright ?? 2003 by The MicroEnterprise Monthly. All rights reserved. Reprinted with permission.