The Top 10 CGI Program Support Queries
A surprising number of people choose a Master Series CGI program for their first script installation. Some who are successful on their first try, send us an email to let us know. We appreciate that. For those who don't write, we trust everything went okay.
We also receive email letting us know when something doesn't go as expected. For commercial programs, we help all we can. For free programs, we help as time allows but also encourage the use of the CGI Forum at /support/ and self-help resources.
Here are self-help resources for answers to questions about CGI in general and installation in particular:
-
The FAQ at /support/faq/ (you can carry the syndicated FAQ on your site, if you wish).
-
The Tutorials section at /library/
Unless otherwise stated, articles mentioned below are linked from the WillMaster Possibilities archives index at /library/
The top 10 CGI program support queries are:
~~ Number 10: I made a form. Now what?
Now you need a program to handle the form data.
When you submit the form, something must happen to the information being submitted. That's what the form handling program does.
Many form handling programs are available. Some are simple to install and use, some are complex and handle data in specialized ways. You'll need to determine what you want to happen with the information being submitted, then select a program or have one made to do that.
Master Feedback from /master/feedback/ is a good form handling Perl CGI script. It simply emails the form information to you, the webmaster.
Master Form V4 from /master/form/ is a bit more complex because it can email selected form information to one or more email destinations, each email custom formatted; and it can maintain a custom database of selected form information.
See the "Writing Your Own Form Handling Scripts" four-part series of articles for an understanding of how CGI programs work in relation to handling information submitted with a web page form.
Also, the articles "Dealing With CGI Installation Jitters" and "The Magic of CGI" might help.
~~ Number 9: My program keeps saying "Internal Server Error"
The answer to the "Internal Server Error" question at the /support/faq/ FAQ page contains a list of possible reasons along with suggestions for correction.
~~ Number 8: What is my Perl location?
The Perl location is the location on the server where the Perl interpreter is location. It is almost always different than the cgi-bin where scripts are installed.
This needs to be answered by your hosting company. No scripts can run without the correct answer.
Once you have the answer, the Perl location must be the first line of the script, preceeded by a pound character and an exclamation character. Most scripts correctly begin with one of the following two lines:
#!/usr/bin/perl
#!/usr/local/bin/perl
If you forget that first slash character, the one following the exclamation point, your script probably won't run. Also, no spaces or blank lines may be before or above that first line.
~~ Number 7: How much do you charge to install this thing?
We install only Master Series CGI programs. Our current installation prices and related information are at /master/installation.shtml
If you need to install programs not from the Master Series, we may be able to provide contact information of someone who can do the installation for you.
~~ Number 6: What kind of databases do your programs use?
We use two kinds --
i. Flat file. This is a plain text file with one record per line, with fields separated (delimited) with a specific character or character sequence. When the file is tab- or comma-delimited, the file can be downloaded and imported into most popular desktop/laptop spreadsheet and database programs. Flat files are usually human readable.
ii. DBI file. These are relational database files manipulated with the help of Perl modules. These are faster to access and update than flat files, in some cases. While some of the content may be human readable, it is not designed to be so.
None of our Master Series CGI programs require database help from other programs, such as MySQL. Each program contains all the code necessary for maintaining the databases it requires.
~~ Number 5: Will your scripts work on NT?
Our scripts are made for Unix/Linux servers. Some might work on NT with little or no modification. Others would require more extensive changes.
The two main differences between NT and Unix servers, as related to Perl programs, are:
i. The default directory location on Unix servers is generally the directory where the script is at, unlike NT servers. If you anticipate changing a script to run on NT, and the script requires accessing files or anything else that relies on relative directory locations, then the directory locations should be specified as the complete directory path, including the drive letter and colon.
ii. The default mailer for most Unix/Linux servers is sendmail or qmail. On NT, sendmail is rare and qmail may not exist. To change such an emailing script for NT will require re-coding sections that send email.
~~ Number 4: The program won't take my password!
The program asks the user to specify a password for future access, and when the user submits the information the program asks the same thing again. And again.
The program isn't storing the new password to file and, thus, "knows" it hasn't received it yet.
When a program won't store data in database files, it usually means the database directory(ies) have incorrect permissions. The program can't create or update files.
On a few servers, permissions 755 will work. But try 766 first, because it is generally accepted that the directories where data is kept should not have permission to also run scripts. If neither 766 nor 755 work, give the directory 777 permissions.
Your FTP program should have a way for you to create directories and change their permissions.
See the "Unix/Linux File Permissions" article for more information.
~~ Number 3: Why can't I use FrontPage to upload scripts?
Although Perl scripts are programs, they're written with plain text. They're used by the server in plain text form.
Unix/Linux operating systems use a different line ending character than do PC and Macintosh. When you tell your FTP program to upload (or download) files as ASCII/plain text, the FTP program will convert the line endings from what the source operating system uses to what the destination operating system uses.
Using FrontPage, a web page form, or other methods or programs that don't convert line endings from PC or Mac to Unix, and vice versa, will almost always result in a broken script.
~~ Number 2: Everything else works, but it won't send mail.
Check the sendmail location. Two common typographical errors are failure to type the leading slash character and failure to specify the -t flag. Example of a sendmail specification:
/sbin/sendmail -t
There is often confusion on whether or not the -t flag is required. Yes, it is, provided the email is sent with formatted headers from which sendmail determines the destination.
Some Perl scripts automatically append the -t flag to the sendmail location that's specified elsewhere in the script. On these, don't specify the flag, the script will do it for you.
Other Perl scripts check to see if the flag is present and, if not, append it automatically.
Both of these situations can foster confusion or even a belief that the -t flag isn't necessary.
Follow the script's installation instructions or examples for the best chance at being right the first time.
If you don't know where your server's sendmail is located and your hosting company is slow coming forth with the answer, you might use Master Pre-Installation Tester from /master/pit/ to find out. That script is also good to find out lots of other things, including correct directory paths and the presence of certain Perl modules.
If you're interested in further study about how to send email with scripts, see the two-part article "How To Send Email With Perl"
[NOTE: Since this article was first published, a new article was written specifically to address problems with sending email by Perl scripts. See Reasons Why Scripts Won't Send Email]
(drum roll)
~~ And the Number 1 query is: This thing doesn't work.
Remember that the script is probably installed and running on dozens or even hundreds of servers. And only malicious people would intentionally distribute non-working programs. This is not to say that a previously hidden bug wasn't uncovered (see the "Bugs, and How They Can Happen" article), but investigate the installation first.
Instructions can be inadequate or misunderstood, or a step might inadvertently be missed, or something else went awry during installation.
When you do report a problem, include all the information you think tech support might need to resolve it. Simply saying, "I installed your script and it doesn't work" won't get it fixed. See the "Better Tech Support" article.
Question:
Did you find this article interesting and understandable? How can it be improved?
Your response is anonymous.
When done typing, click anywhere outside the box. [more info]
Will Bontrager
©2002 Bontrager Connection, LLC
Please note:
Articles on this website are presented "as is". However -
If you have a question about a CGI script, HTML, CSS, PHP, or JavaScript
Ask one of our Experts and you'll have your answer!
Click here for details.
