CGI-bin General Information
CGI stands for "Common Gateway Interface," the "bin"
part alludes to the binary executables that result from compiled or assembled
programs. It is a bit misleading because cgi's can also be Unix shell
scripts or interpreted languages like Perl. CGI scripts need to be saved
in ASCII format and uploaded to your server's cgi-bin in
ASCII or text format. This is very important.
Back to the top
Where to put CGI scripts
Put your cgi-bin scripts in the www subdirectory named "cgi-bin".
Upload them in ASCII format.
Paths to Date, Mail, Perl,
etc.
Here are
your paths to the common server resources that CGI scripts often require:
Sendmail: /usr/sbin/sendmail
Perl5: #!/usr/bin/perl
Serverpath: /home/username/domain-www/cgi-bin/filename
Root path: /home/username/
(puts you in your the root of your account)
Domain directory: /home/username/domainname-www
(puts you in your www directory)
Cgi-bin path: /home/username/domainname-www/cgi-bin
(puts you in your cgi-bin)
NOTE:
Do not include domain extension anywhere you list your domain name.
How To Set Permissions
There are
three different ways to set permissions for your files and directories
within your account. 1) File Manager, 2) FTP, and 3) Telnet.
Setting
Permissions Using Your File Manager:
Log
into your Control Panel and then click on File Manager. You will now see
a list of directories within the root of your account. Since all of your
html files and subdirectories are uploaded and created within your www
directory you need to click on the directory labeled "www".

Once inside
your www folder, you will see, as in all directories, the first column
is the Permissions Column, click on the link pertaining to the directory
or file that you wish to set the settings for and the Permissions screen
will open as seen in the screen shots below. (Refer to Permission Definitions
further down this page for an explanation of settings.

Setting Permissions using Fetch for MAC:
If you have Fetch for the Mac, you have an easy way to change permissions.
Go to the file you want to change the permissions on, and highlight
it. Under the Remote menu, select Change Permissions. A window will
pop up showing the current permissions for the file you had highlighted,
as shown in the screenshot below. Click on the boxes to change permissions
as needed. (Refer to the Permission Definitions further down this page
for an explanation of settings.

Setting Permissions Using WS_FTP for Windows:
WS_FTP accomplishes the same task as above. Just highlight the file
you want to check, and right-click on it. A menu will pop up, then select
CHMOD. You will see the window as shown below in the screenshot we've
provided. Click on the appropriate settings as needed. (Refer to the
Permission Definitions further down this page for an explanation of
settings.

Permission Definitions
Owner
= the files users (you)
Group = the files group
Others = others
Permissions Definitions:
r = read access
w = write access
x = execute access
Numerical Definitions:
r = 4
w = 2
x = 1
Chmod
as a word used for changing Permissions from within Telnet or your FTP
client.
Some scripts will tell you to chmod 775 (for example). When using the
numeric system, the code for permissions is as follows:
4 + 2 + 1 (rwx) = 7
The first number applies to Owner, the second number applies to Group,
and the third number applies to Others. Therefore the first 7 of the
chmod 775 tells Unix to change the Owner's permissions to rxw (because
r=4 + w=2 + x=1 adds up to 7, this giving the Owner Read, Write, and
Execute Permission. The second 7 applies to the group, this giving the
Group Read, Write, and Execute Permission, and the last number 5, refers
to Others (4 + 1= 5), giving Others only Read and Execute Permission.
The permissions for chmod 775 look like this: rwx rwx -rx.
Permissions are always broken up into three groups of letters, however
if there is a dash, this dash simply means that Permission wasn't given
for that particular function, for example in the chmod 775, Permission
to Write was not given to Others.
Remember: the first 3 letters always apply to Owner, the second 3 apply
to Group, and the third 3 apply to Others.
Troubleshooting CGI-bin
Problems
Below
are solutions to some of the more common CGI script problems.
When I activate my CGI program, I get back
a page that says "Internal Server Error. The server encountered
an internal error or mis-configuration and was unable to complete your
request."
This is generally caused by a problem within the script. Check your
script settings again to see that you have entered the correct server
information and have set the correct permissions for the script. If
this information is correct, you'll need to contact whoever wrote or
is distributing the script for further assistance.
I am being told "File Not Found,"
or "No Such File or Directory."
Upload your Perl or CGI scripts in ASCII mode, not binary mode.
When I test my Perl script in local mode (by
Telnet), I have the following error: "Literal @domain now requires
a back slash at myscript.pl line 3, within string. Execution of myscript.pl
aborted due to compilation errors."
This is caused by a misinterpretation by Perl. You see, the "@"
sign has a special meaning in Perl; it identifies an array (a table
of elements). Since it cannot find the array named domain, it generates
an error. You should place a back slash (\) before the "@"
symbol to tell Perl to see it as a regular symbol, as in an email address.
I am getting the message "POST not implemented."
A possibility is that you are pointing to a cgi-bin script that you
have not put in your cgi-bin directory. In general, this message really
means that the web server is not recognizing the cgi-bin script you
are calling as a program. It thinks it is a regular text file.
Back to the top
|