Script Troubleshooting
Scripts can be challenging to get working, it is best to go about installing them with a methodical step by step approach.
This document has been written with the following assumptions:
You have a basic understanding of paths.
You know how to upload and change file permissions with an
FTP program.
All perl scripts have a line at the top called the "shebang line" This line usually looks like one of the two examples shown below.
#!/usr/bin/perl
#!/usr/local/bin/perl
Your web hosting service will most likely have an information page outlining what their server requires for a shebang line.
Included with my scripts is a file called
cgitest.cgi. This script should be uploaded to the server and executed by accessing it directly with your browser. Before you actually execute it though you will need to assign the correct permissions to it.
Permissions in the Unix Environment
All cgi scripts uploaded will need their chmod changed to 755. It used to be common practice to chmod all files to 777 (a wide open setting) until everything was working and then pare down the permissions after a successful install. This is no longer a recommended practice as some servers run programs that detect settings and will not allow the script to be executed until it is assigned a non-world writable permission. It is a security hole to have a script set to world write.
The first number represents "Owner" the second "Group" and the third "World".
Read is worth 4
Write is worth 2
Execute is worth 1
A chmod setting of 755 give the owner "Read, Write, Execute" permission. Group and World get "Read, Execute" permission.
If you place the script in a folder you will need to chmod the folder to 755 as well.
After the permissions have been changed try and execute the script cgitest.cgi, it should return the text "Hello world!" to your browser if it does you have successfully installed the script.
If it doesn't there is some kind of problem. Check to make sure the permissions are correct by viewing the directory information with your FTP program.
Check to make sure the ext. "cgi" is one the server recognizes; you might have to change it to "pl"
There could also be a problem with the text editor you used to edit the shebang line. A cure for this is to upload the script in ASCII, download BINARY and then upload ASCII again. This will remove the characters your Windows environment put in that the Unix box did not like. I use a program called
Context it is available for free on the internet. It is a great text editor for many programming languages.
The next vital piece of information we need is the path to your cgi-bin as perceived by the perl interpreter. The file
pathtest.cgi can help you to determine this. Upload it to your server and execute it, you will have to chmod it and put the correct shebang line at the top.
When executed it will display a list of information. The path we want will be printed next to this line:
"SCRIPT_FILENAME ="
Use this path wherever the script needs a path from the perl interpreter.
Incorrect paths are usually the main obstacles in getting a script to function correctly. It can get confusing especially when the script is accessing files in the HTML public folder as the TopForm script does. In the TopForm script we have a situation where the perl interpreter has to read through the HTML document to use it as a template in the generated cgi page. To point the interpreter to the correct spot we could end up with a line like the following:
/f3/ca/yourdomain.com/cgi-bin/topform/../../html
It is a bit daunting looking at a path like this but if you break it down it makes it more clear.
In the example above the cgi-bin is above the HTML folder. There is the path from the perl interpreter to the cgi-bin in red and then the cgi-bin itself and then the topform folder within the cgi-bin. From the interpreters point of reference the path leads back to the topform folder and then it climbs up a level into the
cgi-bin and then up out of the cgi-bin and into the HTML folder. The "../" move us up a level.
If at some point nothing seems to be working step back and look for other problems like uploading to the wrong folder or viewing the wrong instance of the page. Remember the Unix environment is case sensitive. The point I am trying to make here is there are a multitude of things you could be doing wrong especially if you're tired. Another thing is to make sure the page is actually refreshing, if you press Ctrl+Alt and then refresh it will drag a new instance of the page to your browser. Sometimes this has to be done each time if there is a proxy server between your machine and the pages your editing.
I have also run into problems with write permissions on servers. Some scripts need to write to the server and if the system does not have write privileges writing will not be possible.
To test this, upload the
testwrite.cgi file to your server, don't forget to chmod it and put the correct shebang line at the top. If the system has the correct permissions the script will execute without error, write a file to the server called test.dat and the browser will return the message "Hello World the file test.dat was created".
As time permits I will add to this document, I will also be making instructions available for each individual script.