This page researched and written by Tom Irish,
owner, webkewl design
While we have focused more on services that are hosted on remote servers, I thought it might be nice to give this alternative some attention. Perl has been said to be the glue that holds the net together and indeed, Perl scripting is responsible for a wide variety of applications on the web. If you are already familiar with using cgi's and Perl, you probably want to go back to the goods at this point.
It is important that you check with your ISP or host before attempting to use cgi scripts. Some of the scripts mentioned here require the use of Server Side Includes and even though your ISP or host may allow cgi scripts, they may not permit SSI's. Most providers have instructions about this on their site. When in doubt, contact the webmaster (and you may be required to).
That said, if you know your way around html and can read and take direction well, you should be able to use these scripts. It will take a bit of time and patience but the benefit is greater control of your webspace. While you can get a free poll from a remote server for your site here, when a visitor sees the returns they also see two banners and a button. If this is out of character for your site, but you would still like a free poll - we found a script for you. :-)
All of these scripts come with a certain level of documentation. Usually, you will have at least a script with a .pl or .cgi extension, and an html example, and most often a few more files. For instance, a FormMail script would contain the script, and a sample of the code needed in your html file to send information to the script. In the case of formail, the script returns this information to someones email address. In others, the script returns the information to other html documents or makes changes to the present one.
The scripts themselves need to be opened in a text editor. Here you will find the script thoroughly commented. It will tell you what each section does and prompt you as to where you need to make edits. A # symbol lets the perl interpreter know that it is to ignore what follows unless it is followed by an !. The first line in most of these scripts will look similar to this: #!/usr/bin/perl. This is the path to the perl interpreter on the server from the directory where your .cgi or .pl script will reside. Your host should either have this information for you or you can find it by telnetting the server. If you need information about telnet, please check the documentation that comes with your telnet application.
If your script requires that you alter some of the html that it returns, you will need to be aware of a couple of things. First, each line must end with \n which tells Perl there is a new line. Second, you must escape any double quotes with a \ . Here is a sample of what a line of html being returned by a Perl script looks like:
print "<a href=\"$return_url\">Click here submit your vote.</a></p>\n";
Notice how the entire line after the word "print" is within quotes and ends with \n. Also note how the backslash is used with the double quotes around the url (you will see a semi-colon at the end of each statement). Each line of any html the script returns must follow these rules.
Once you have set-up the perl script to do your bidding and configured your html page(s) and any other pages included with the script, it is time to upload and test your work. Most often you will be uploading your scripts to a directory you have created called either cgi-bin or simply cgi. Again, this is a point to contact your host on as the instructions and permissible uses vary widely.
You will need to set permissions for each file you put in the cgi directory. Required permissions will be spelled out in the script instructions. You can set permissions either with your ftp client or via telnet. Refer to the application documentation to find out how to go about it for that application. The following however, should provide an understanding of what you are doing.
You will often see "set permissions to chmod 755 or chmod 744". In
Fetch, when setting permissions you instead see check boxes determining whether
the owner, group, or everyone have permission to read, write or execute the
file. Each number represents these
conditions. The place determines owner, group, or everyone. Take 755. The first
7 means that the owner has permission to do all three (read, write, execute).
The following two five's give group and everyone (also called other) permission
to read and execute but not write. 744 would allow the owner all permissions,
while group and everyone would have read only permission.
7 = read, write, execute
4 = read
2 = write
1 = execute
5 gives read and execute because 4 + 1 = 5.
Using telnet, while in the directory you would issue the command "chmod 755 filename.pl" to set the permission to that file to 755.
You may also need to set permissions for html and txt files. In this case you will likely be instructed to set the permission as 644 or similar. For a more thorough discussion of permissions, I found this providers manual to be quite thorough.
Ok, so the files are up, the permissions are set, and it doesn't work. Permissions tend to be the greatest cause of failure for these things. Second is filenames not pointing to the right places. Make sure that your html file(s) points correctly to the script. Double check your permissions and your work. Check to make sure you have followed the rules in setting up html being returned by the script. The only way to make it work is to jump in and get your hands dirty. Hopefully this document has given you enough information to want to dive in.
For a more detailed description of permissions and other things Unix: http://www.gnu.org/manual/findutils-4.1/html_mono/find.html#SEC61
A tutorial on writing a script in Perl: http://www.ravensclaw.com/~pmaster/perl/tutorial/index.shtml
The BSDI Man Pages
-
www.perl.com
www.macperl.com
