Frequently Asked Questions

If you can't find the answer to your question here, check out the CGI forum.

FAQ Index:

What is the difference between a directory path and a URL?

Why do my permission settings keep changing? I CHMOD my scripts and directories like I'm supposed to, then later I find they have been changed.

How do I figure out "the location of Perl on my server"?

My CGI program came in a .zip file. How do I open it?

What is a "ASCII /plain text editor"?

My site is hosted on an NT server. Can I run Perl CGI scripts made for Unix, such as the Master Series scripts?

Help! I am trying to install a cgi script and keep getting a message like "Internal Server Error. The server encountered an internal error or misconfiguration and was unable to complete your request."

Help! I am trying to install a cgi script and keep getting a message like "Premature end of script headers".

What do I do about a "... malformed header from script. Bad header=No recipient addresses found ..." error?

How do I install Perl modules?

The script can't find pages that I know exist. Why? (For scripts using the LWP::Simple module.)

My script does everything it's supposed to do -- except, it won't send email. Why?

It doesn't work!

What is the difference between a directory path and a URL?

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}

How do I upload my CGI program?

Use an FTP program. http://tucows.com has many available for download.

Upload your CGI program as ASCII/plain text rather than as binary. Uploading as ASCII/plain text allows your FTP 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. 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.

Getting Started with FTP is a useful tutorial. (Opens a new window)

{top}

Why do my permission settings keep changing? I CHMOD my scripts and directories like I'm supposed to, then later I find they have been changed.

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}

How do I figure out "the location of Perl on my server"?

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}

My CGI program came in a .zip file. How do I open it?

These programs are available for "unzipping" the ZIP file:

Macintosh:

MacZip (fat) Free download.

Win95/98/NT:

PowerArchiver $19.95

Win3.1/95/98/NT:

WinZip $29.00
{top}

What is a "ASCII /plain text editor"?

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.

Macintosh:

SimpleText - comes with the Mac but it is limited to 32k file size. BBEdit — the "lite" version is free.

PC:

NotePad comes with Windows but it is limited to 32k file size.

I use Arachnophilia for almost all of my development work (version 4.0, not the Java version, although the Java version probably does a good job, too). It does not have a file size limitation and is a handy piece of software — simple to use yet with powerful features. Being kind to everyone you meet for one day of your life, the best you know how, is the price for Arachnophilia.
{top}

My site is hosted on an NT server. Can I run Perl CGI scripts made for Unix, such as the Master Series scripts?

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://www.cgi-resources.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:

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.
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.
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. TuCows.com has links to FTP programs for many platforms.
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.
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: #!
The location of Perl 5 is incorrectly stated on the first line of the script following the #! characters. To fix, type the correct location.
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.)
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.
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.
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}
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.

Help! I am trying to install a cgi script and keep getting a message like "Premature end of script headers".

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:

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.)
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.
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 http://willmaster.com/master/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}

What do I do about a "... malformed header from script. Bad header=No recipient addresses found ..." error?

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}

How do I install Perl modules?

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 (http://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 http://search.cpan.org/dist/libwww-perl/ has information and links to download the LWP module.
{top}

The script can't find pages that I know exist. Why? (For scripts using the LWP::Simple module.)

Verify that URL is valid. It's easy to introduce a typographical error. To verify, copy the URL that the script is looking for, copy from the same place the script is getting it from, and then paste the URL into your browser.
LWP::Simple will not retrieve pages from a secure server because it is unable to negotiate a secure connection. LWP::Simple will work only with HTTP URLs.
If a page is in a password protected directory, the LWP::Simple module can't get the page. It is unable to negotiate passwords.
If a page is in your cgi-bin, the module probably can't get the page. Check the URL with your browser; LWP::Simple can get the pages at http://... URLs whenever browsers can.
The module LWP::Simple may be misconfigured. Test it with this short script:
```
#!/usr/bin/perl
use strict;
use LWP::Simple;
my $page = get "http://willmaster.com/";
$page = "Error: $!" unless $page =~ /\w/;
print "Content-type: text/html\n\n";
print $page;
```
If the above displays the WillMaster.com page, then that part of the module is configured okay. However, there is more to test.

On line four of the test script, you'll find a URL between the quotes. Change that URL to the URL your production script isn't finding. Then run the test script again.

If this test script gets the page but your production script does not, then the fault is with the production script. However, if the test script does not get the page (your browser just displays a blank window), then LWP::Simple is misconfigured. You'll need to contact your hosting company and have them take care of it. (Give them the URL to the test script so they can verify your test.)
{top}

My script does everything it's supposed to do -- except, it won't send email. Why?

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.

It doesn't work!

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.

WillMaster > Support

Fast Answers

User Manuals for our Commercial Software

Subscribe to
the Possibilities Ezine

Frequently Asked Questions

WillMaster > Support

Fast Answers

User Manuals for our Commercial Software

Subscribe tothe Possibilities Ezine

Frequently Asked Questions

Subscribe to
the Possibilities Ezine