Keep in mind that SupportBot can provide you with detailed script configuration information and even find/fix errors in cgi scripts you install on your site.
"When I activate my CGI script, I get back a page that says 'Server
Log on via SSH and go to your www/cgi-bin directory. Try running the program
manually to see what errors you get.
Remember that when a CGI script
produces error output, that output is discarded and you get the
non-specific page you saw. To check on it, you'll have to run it
If you get something like
bash: ./search.pl: No such file or directory
and you know you typed the name correctly, it's almost certain you
uploaded the script from your PC or Macintosh in binary mode. Perl
scripts are ASCII text and must be transferred in ASCII mode. (So are
shell scripts and any other kind of script that starts with '#!' on
the first line.) You know it's this if ./search.pl doesn't work and
perl search.pl does. Assuming you don't have any legitimate carriage
returns in the program (doubtful), this will fix it:
mv search.pl search.pl.txt && tr -d '\r' search.pl
Then there's this response:
Literal @Clockwatchers now requires backslash at ./bigones line 16, within string
Many scripts that you'll find widely distributed are still written for
Perl, version 4. Our /usr/bin/perl is version 5, which is 99.9%
compatible with version 4, along with many improvements. You've found
the other 0.1%.
In Perl 4, you could get away with a statement like
$mailaddress = "firstname.lastname@example.org";
because Perl didn't think the '@' sign was special in a string. Perl 5
does, so you need to escape it, like so:
$mailaddres = "joe\@schmoe.com";
You can't just change all the '@' signs to '\@', only the ones in
strings. To speed your search, however, Perl gives you the line number
of the problem line(s) in its error message. (To check for them
without accidentally running the program, if that would be a problem,
use perl -c script.) Fix them, and see if it works.
Tom Christianson (well-known in the Perl world) has written The
Idiot's Guide to Solving Perl CGI problems for the comp.lang.perl.misc
newsgroup. Not everything in there is correct for the Clockwatchers setup,
but it's useful.
2. ASCII And Binary Modes
So why this section? If this seems obvious, sorry, but probably the
single biggest type of problem we have to correct or tell users to do
over is problems caused by having the wrong mode active. We needed
this so you'd find it.
Macintosh users: in Fetch, the binary mode referred to throughout the
manual is 'raw'. The other option uploads too much data, corrupting
the file. ASCII mode is 'text'.
In case you're wondering what the fuss is about -- aren't text files
standardized? --. While ASCII is a standard for
encoding text, it does not specify how to end lines. There are two
obvious candidates in the ASCII character set: CR and LF. (Carriage
Return and Line Feed.) *nix machines, such as the Clockwatchers web
site hosting servers, use LF to terminate lines.
Macintoshes use CR. DOS, Windows,
and NT machines use CR LF (both, in that order). When transferring
files between machines of different types, you need to account for
this, hence ASCII mode. To avoid damaging binary files (where the
bytes don't have the ASCII semantics) there is binary mode.