Chapter 4 - CGI-bin

IN THIS SECTION

CGI-bin General Information | Where To Put CGI Scripts | Paths to Date, Mail, Perl, etc.
How To Set Permissions | Permission Definitions | Troubleshooting CGI-bin Problems
Back To Table Of Contents



CGI-bin General Information


CGI stands for "Common Gateway Interface," a fancy name meaning computer programs running on the web server that can be invoked from a www page at the browser. 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.

This chapter provides you with information needed when configuring scripts and other information regarding your CGI-bin.

Back to the top



Where to put CGI scripts


Put your cgi-bin scripts in the public_html subdirectory named "cgi-bin".

Back to the top



Paths to Date, Mail, Perl, etc.


Here are your paths to the common server resources that CGI scripts often require:


Date:  /bin/date



Sendmail: /usr/lib/sendmail  OR  /usr/sbin/sendmail 
depending on which machine you are on. If one wont work, the other will. Perl5: #!/usr/bin/perl Serverpath: /home/username/domain-www/cgi-bin Root path: /home/username/ (puts you in your the root of your account) Domain directory: /home/username/public_html (puts you in your public_html directory) Cgi-bin path: /home/username/public_html/cgi-bin/filename (puts you in your cgi-bin)
NOTE: Do not include domain extension anywhere you list your domain name.

Back to the top



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. We DO NOT encourage the use of Telnet if it is only being used for setting permissions and will forego its explanation here.

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 public_html directory you need to click on the file folder next to the public-html directory name. The directory will open and in the upper right hand corner, there will be a list of actions that you can perform for that directory. Next click on the file icon located next to the text name of the file that you are wanting to change permissions for. Again, in the upper right hand corner you will see a list of actions that you can perform with this file, simply click on Change Permissions and select the appropriate permissions and save.

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.



Back to the top



Permission Definitions


Owner = the files users (you)
Group = the files group
Others = others

Permissions Definitions:

r = read access
x = execute access
w = write access

Numerical Definitions:

r = 4
x = 2
w = 1

You will come to recognize, if you do not already, 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.

Back to the top



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."

You are probably using the wrong reference for cgiemail. Use the reference /cgi-bin/cgiemail/mail.txt. Another 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






©Copyright 2000 . All Rights Reserved.
The entire contents of this site is copyrighted and may not be reproduced for any purpose without prior written permission.
Table Of Contents:

Back To Index
|
Chapter 1
FTP Instructions

|
Chapter 2
SSH / Telnet

|
Chapter 3
Email Software Setup

|
Chapter 4
CGI Bin

|
Chapter 5
Secure Server

|
Chapter 6
Formmail

|
Chapter 7
Microsoft Front Page

|
Chapter 8
CGI Scripts

|
Chapter 9
COMING SOON

|
Chapter 10
COMING SOON

|
Chapter 11
Streaming Audio/Real Video

|
Chapter 12
File Manager

|
Chapter 13
Mail Manager

|
Chapter 14
Changing Passwords

|
Chapter 15
Site Statistics

|
Chapter 16
Network Tools

|
Chapter 17
FTP & Anon FTP

|
Chapter 18
SSH / Telnet

|
Chapter 19
Password Protect Directories

|
Chapter 20
Custom Error Pages

|
Chapter 21
MySQL

|
Chapter 22
Mime Types

|
Chapter 23
Crontab

|
Chapter 24
Entropy Chat

|
Chapter 25
Shopping Cart

|
Chapter 26
Search Engine Submission

|
Chapter 27
PGP

|
Chapter 28
Subdomains

|
Chapter 29
Archive Manager

|