 |
|
Support
CGI Tutorial
What is CGI/Perl?
Perl was originally designed to be a enterpretuer to help UNIX users
with commen tasks. However, with the explosive growth of the Internet it
has been adapted to be a excellent interface to the web.
Perl has become the preferred programing language for making websites
dynamic and user interactive. For example, you can use Perl to grab the
data from your webpage forms and perhaps write this data to a file (as
in a guestbook) or send it to you via E-mail (as in a form). We will
discuss some of the basic principles to running PERL.
TOP
Links to places where you can learn CGI/Perl
The following is a list of sites we recommend for persons interested in
learning the acutal programming language of Perl. This tutorial does not
get into the syntax, we only discuss configuring your scripts for use on
our server.
Visit the following list of sites if you are interested in learning Perl:
http://www.web-consult.com/perl.html
http://www.extropia.com/tutorials.html
http://lightsphere.com/dev/class/
TOP
Links to free CGI/Perl archives!
Because of the enormous popularity surrounding Perl, many websites have
becomed devoted to its growing success by offering free CGI/Perl scripts
to visitors. The following list of websites offers quality CGI/Perl
scripts that have been tested on our server. We have ranked the websites
in decending order.
CGI Resources
- Run by the same person (Matt Wright) as Matt's Script Archive.
TOP
Where Perl is on our server and where you can obtain the souce
code!
Perl is located in the following places on our server:
- /usr/bin/perl5.xxx
- /usr/bin/perl
- /usr/local/bin/perl
- /usr/man/man1/perl.1
You can obtain the origianl Perl souces code from the following website:
TOP
Setting your permissions on your CGI
scripts properly.
If you plan on running or linking to CGI script using the above method set
your permissions accordingly: CGI FILE -- 700 or
(Owner=execute/write/read, group=nothing, world=nothing)
DATA FILE that the script writes to but is not viewed on the web) -- 600
or (Owner=write/read, group=nothing, world=nothing)
DATA FILE that the script writes to and is viewed on the web (example:
guestbook) -- 644 or (Owner=read/write, group=read, world=read)
The above permissions will insure MAXIMUM security.
Note: NEVER set your permissions on a file or directory to 777 as
our server will not allow the script to execute because of the potential
security hazzard.
TOP
Using the correct extensions for your
CGI scripts.
If you are using a CGI script that you plan on being viewable by anyone
(that creates output in the form of HTML), the it must have the .cgi
file extension. If you try to do this with the .pl extension, it will not
work.
The .pl extension will work in all other cases. However, we strongly
suggest you use and only use the .cgi extension for your Perl scripts.
This is a good habit and will factor out any problems relating to your
scripts because of the file extension used.
TOP
Configuring your varibles so that your
CGI scripts will run properly.
Varibles are the part of the script you must configure so that the script
knows where your files are and where data should be recorded. Absolute and
URLs will most likely be used in the variables so you need to know what
these are.
An absolute path is the path to a certain file or directory on the server.
For example, the script might want to to set a varible ($links) to the
absolute path to your links.cgi file. Below is what this should look like
when configured properly.
$links="/home/your_login/public_html/cgi-local/links.cgi";
The script may also ask for the URL to this file (links.cgi). If the
varible were $linksurl, we would set it as follows.
$linksurl="http://www.yourdomain.com/cgi-local/links.cgi";
CGI scripts obtained from free archives not made by you will almost always
require you to set varibles as we have done above. This is the most common
source of problems with CGI scirpts not working properly so make sure your
varibles are set correctly!
TOP
Debugging your CGI scripts through Telnet.
One of the most powerful features of Telnet is that you can pinpoint
problems in your CGI scripts. Unlike the HTTPD protocol which displays
the infamous "Internal Server Error" message, telnet will tell you what
is the real problem!
To test your script, you must execute it on the server which means your
permissions must allow you (the user) to execute the script. Otherwise,
a permission denied message will occur.
Telnet into the directory where the script you wish to test resides.
Lets say that the CGI script named "links.cgi" is giving us problems! To
find the problem, type in "./links.cgi". The server will then execute
the script and tell you what, if any problems occur. The syntax for this
command is "./script_name".
After you have found the problem, you can edit your CGI script using
PICO in Telnet, then test it again. Eventually you will get your script
working, and much faster than trying to pinpoint the problem yourself!
Note: 95% of the time, the problem is either the permissions on the
script(s) are not properly set or the scripts(s) varible(s) are not
properly set.
TOP
Other useful links to CGI/Perl tutorials.
The following list of websites offer troubleshooting and tutorials on
CGI/Perl:
TOP
|
|
|
