Get Ready to Program

Your script is just a text file that contains Perl code. You can use any editor to write that code. You need to put your script where the server can find it, and different servers and different ISP's have various policies on what that means. Some ISP's require all CGI scripts to live in a special directory, while others allow you to simply name the file with a certain extension (often .cgi). Other servers identify CGI scripts by MIME type, believe it or not. Ask your ISP what their policy is. Of course if you are running your own server and Linux workstation you'll know where to put the files by consulting your server documentation.

There are a few things you need to be aware of when getting setup to program CGI that do not vary (too much) from server to server, and we'll address those here.

The shebang Line

When the server is instructed to execute the script and send the results back to the client, the code you write within the script is compiled by the Perl engine and executed. Therefore the first thing you have to do is indicate which engine you want to use to run your script. Do this with the "shebang" line. The very first line of your script must always be the path to the Perl engine (or interpreter) on your Unix system, preceded by a # sign and an exclamation point.

 

You might also see this called the magic line, or "a bit of magic". People say this because this method of finding the correct interpreter is actually a hack, done by somebody so long ago that it has become standard. Like many classic hacks it's almost impossible to understand or describe why and how it works, so people say it's magic instead, and, well, it basically is.

You can find the path to your Perl engine by typing "which Perl" at the command prompt of your system. For instance, if you typed:

 

%which perl

and the system prints:

 

/usr/bin/perl

your shebang line - the very first line of the script - would be:

 

#!/usr/bin/perl

Setting Permissions

If you're creating your CGI script on a multi-user operating system (like Linux) be aware that your server also has certain privileges in the system. In other words, your server itself is like a user, and different users can run different programs based on the permissions their userid is allowed. In order to be run by the server your script will need its permissions set such that the server's userid and group have permission to execute it. Any directories the script lives within, and any files the script must access also need their permissions set. On Linux use the chmod command to make sure your script has execute permission for you and everybody else, including the server.

 

%chmod a+x my_script.cgi

%

Although all scripts require the execute permissions above, the exact permissions you may need will depend on the policies and settings of your ISP. Ask them; if they don't know or cannot answer your question, get a new ISP immediately!

 

You may also see this described as "setting the bundle bit". Don't let that bother you.

Test your Script

To test to see if your script is currently working add this statement to your script:

 

#!/usr/bin/perl
print "cheese";
exit;

Save your file, set your permissions (if you haven't already) and type from the command prompt:

 

%perl my_script.cgi

If it prints cheese back at you, then your script is working. Of course, this will not tell you if your script is working as a CGI script, we'll show you how to test that in a moment.

 

All Perl statements end with the ; character. It's the first thing to look for if your script stops working

.

Checking your Script's Syntax

Perl also has a built in tool to check the syntax of your script, which can be very useful for finding errors as the script gets more complex. You use this tool by invoking it with a command line c flag:

 

%perl -c my_script.cgi

my_script.cgi syntax OK.

Planning your Work

For most people the development of a script is a give-and-take process of testing and refinement. From the first line to the time you are done you could run your script hundreds of times to see what it outputs and track down bugs. When developing your scripts it is essential to examine their output, as that's what you're trying to do here, after all: output stuff.

As we said before, most CGI scripts have three distinct parts: understanding and securing user input, processing and sorting data, and sending back results. Each of these parts of a script has its own particular concerns and challenges; we find it useful to be conscious of these areas when creating our scripts. Planning your architecture should help you keep everything clear and simple in your head, and make sure your script covers all the bases.

In this article we'll cover setting up a functional CGI script that can understand what is coming in and send back results. We'll look in detail at what happens in the middle - processing and sorting data - in the next few articles.