Frequently Asked Questions about CGI

A directory path represents the directories on your server (and on your home computer, too) that are navigated when going from one directory to the location of another directory or to a specific file in another directory. The path is printed as a list of directories separated by slashes.

A directory path, for those used to DOS or Windows, would be something like C:\programs\utilities or C:\programs\utilities\program.exe. On UNIX it would be something like /usr/www/domain/cgi-bin or /usr/www/domain/cgi-bin/program.cgi

A URL, on the other hand, represents a file on a server somewhere on the Internet. It can reference the same file on a server as a directory path. The syntax begins with http:// or https://, like http://domain.com/page.html

{top}

Use FTP or SFTP to upload your CGI program. Upload as ASCII/plain text rather than as binary. Uploading as ASCII/plain text allows your FTP/SFTP program to change the line endings to comply with the requirements of the destination computer. (Windows, Macintosh, and UNIX all use different line endings for their text files.)

FTP means File Transfer Protocol. SFTP means Secure File Transfer Protocol. Use the tool for the job. It's your friend. Other systems, such as Front Page and even some so-called "upload control panels" can break scripts or fail to fix line endings.

{top}

If you're using WS_FTP, this may be the problem:

The dialog box used to change permissions should not be used to see what the current permissions are. When you use the dialog box, it is at default or at the settings you last used.

Because office computers usually have the current state displayed in settings dialog boxes, this WS_FTP behavior can be confusing. Just remember that the permissions dialog box is only for setting permissions, not for viewing existing settings.

The view the current permissions, use the DirInfo button. If you've changed permissions since the last directory refresh, click the Refresh button before the DirInfo button.

{top}

You'll need to obtain that information from your hosting company. Their technical support can provide you with that information, or they might have an on-line manual you can consult.

The location is probably one of the following:

#!/usr/bin/perl
#!/usr/local/bin/perl

Once you have the location of Perl on your server, you have the information for the first line of every Perl program you install. And once you have that, you can install utility CGI programs that can help you find out the location of sendmail, your document root directory, and other information- (Master Pre-Installation Tester, for example.)

{top}

Both Mac and PC come with utilities to decompress ZIP files.

Third-party software is also available. An Internet search for "ZIP software Mac" or "ZIP software PC" will list choices.

{top}

Think plain text. An ASCII text editor saves information as plain text. If your word process saves with text attributes such as bold, underline, font sizes, font changes, or any way other than plain text, it is not an ASCII text editor.

Mac:

TextEdit (comes with the Mac)

TextWrangler

PC:

NotePad (comes with the PC)

Arachnophilia

{top}

In general, Perl CGI scripts made for UNIX are portable to NT except those that send email.

UNIX servers have a handy-dandy emailer on board, called sendmail. It is used so much because it is so easy to program for.

This sendmail is not prevalent on NT like it is on UNIX, so scripts doing emailing will need to be modified for NT.

A method of sending emails that is available on most internet servers of all operating system is SMTP. It takes a bit more programming to utilize SMTP, but I expect more and more scripts to do so in the future because of the rising demand for NT compatible scripts.

You can find some NT scripts at The CGI Resource Index. See http://cgi.resourceindex.com/

{top}

This one could be so many different things. If you have access to your server's error logs, it can help a lot in determining the reason. Usually, it indicates one of the following:

1. The script was edited with a word processor other than ASCII/plain text. To fix, grab another copy of the script and edit with NotePad or BBEdit.

2. The script was edited with FrontPage or other WYSIWYG web page editor that might have inserted extraneous characters. To fix, grab another copy of the script and edit with NotePad or BBEdit.

3. The script was uploaded with something other than an FTP program. FTP programs can correct line ending characters when up/downloaded from one operating system to another — other programs or web page forms might not be able to do that.

4. The script was uploaded to the server as a binary file rather than as ASCII/plain text. To fix, upload the script as ASCII/plain text.

5. There is a space or blank line at the top of the script. To fix, make sure the first two characters of the script are: #!

6. The location of Perl 5 is incorrectly stated on the first line of the script following the #! characters. To fix, type the correct location.

7. When the script was edited, an apostrophe, a quote, or a semi-colon was inadvertently deleted or added. To fix, carefully compare your edits with the original and fix any errors found. (You kept a backup copy of the original, right? If not, grab another copy for backup.)

8. A Perl module that the script uses is not available on your server. To determine whether or not this is the case, look through your script for lines beginning with the word "use", like

   use _______;

   (the underscore indicates the name of a module). The "use" statements are usually near the top of the script or following the user customization area.

   You can test your server to see whether or not certain Perl modules are installed with Master Pre-Installation Tester.

   If a module the script uses is not available on your server, it will need to be installed before the script will run. Installing modules can be rather technical, so you may wish to ask your hosting company to do it for you.

9. The script is installed in a directory that hasn't been configured to run Perl CGI scripts. To fix, install in an appropriate directory. Your hosting company can tell you which directories can run scripts.

10. The path to sendmail is incorrect. To fix, correct the path. (The three most common typographical errors are forgetting the "/" character at the beginning of the path, spelling "/usr/" as "/user/", and forgetting the " -t" [space,hyphen,t]at the end.)

    {top}

11. Your script is trying to send an email with a non-existent or invalid destination email address.

    If your script uses configuration files with email addresses or if email addresses are hard coded in the script, verify those are present and correctly formatted. Also, if your script processes a form, verify that the field names are spelled correctly, especially the ones having to do with email addresses. (Form field names are case sensitive.) If a script mails to an email address provided on the form, that form field should be required to be filled in.

{top}

A "Premature end of script headers" error usually means that the script was trying to send something to the browser (such as a web page) but the browser wouldn't accept it. The browser must first be told what is coming (called header information) and then the data can be sent.

So when a script gives that type of error it can mean the script is sending data to the browser by default because a file wasn't opened correctly.

Another reason for that error is if the script quits running before anything was sent to the browser. CGI by definition must send something to the browser. So if the script ends prematurely, before it had a chance to talk to the browser, that will cause a "Premature end of script headers" error.

Now, the above is rather technical in nature and you usually don't have to concern yourself with those details. They are mentioned so you have an understanding of what situations usually cause this error.

If you have a proven script (not in beta, for example) you can know it is not the internal code giving the problem.

These are things to check:

1. Ensure that all the directories the script requires are available and that they have the correct permissions. (UNIX directory and file names are case sensitive.)

2. Ensure all files are in the correct directories. For example, if an email template is required, make sure you have put it where the script expects to find it as described in the installation instructions.

3. Although its absence would usually spawn a different kind of error, make sure your server has all the required Perl modules available. If you need to find out, you can use Master Pre-Installation Tester from https://www.willmaster.com/software/pit/ (free script that prevents a lot of hair pulling)

If all of the above are okay, you may want to grab a fresh copy of the script and start from the beginning. It's rare, but it's possible transmission during download or upload of the previous copy corrupted the file.

{top}

It appears that the script is trying to email to a destination that isn't a valid email address.

If your script uses configuration files with email addresses or if email addresses are hard coded in the script, verify those are present and correctly formatted. Also, if your script processes a form, verify that the field names are spelled correctly, especially the ones having to do with email addresses. (Form field names are case sensitive.) If a script mails to an email address provided on the form, that form field should be required to be filled in.

{top}

In most cases, your hosting company needs to install Perl modules. When a module is installed, it can benefit all of their hosting customers on that server.

It some cases, it is possible to install modules in a domain's cgi-bin. Installation requires expert knowledge and experience; a tech at your hosting company may need to guide you.

If the module you require is available at CPAN (https://www.cpan.org/) and your hosting company can't or won't install it on the server where all their customers can benefit, especially if the module is one often used by Perl scripts (such as LWP::Simple and other modules that have to do with retrieving pages from and sending information to remote sites), then it may be time to consider using a different hosting company.

Many scripts that retreive pages from the internet now require the Perl module LWP::Simple for their operation. Most hosting companies have the module installed on their servers. If yours doesn't, the page https://metacpan.org/release/libwww-perl has information and links to download the LWP module.

{top}

There are a number of possible reasons. The three most common errors are typographical: Forgetting the "/" character at the beginning of the path, spelling "/usr/" as "/user/", and forgetting the " -t" [space,hyphen,t]  at the end. If the above is not the reason, read the "Reasons Why Scripts Won't Send Email" article for other possible reasons.

{top}

While you know what's happening or not happening, provide more than just that statement when you contact a programmer or tech support for help. The statement is, frankly, not very informative. The time required to resolve the issue, and possibly the frustration, too, will mount while the nature of the "not working" is clarified.

When asking for help, always state what the program/system is doing that it should not be doing, and/or what it is not doing that you think it should. If the problem is with a form or form processor, include the URL of the form in question. Include any information you think might help resolve the problem. But don't, as a general rule, include any usernames or passwords.

{top}

Email Support

FAQ about CGI