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.

1. Troubleshooting

"When I activate my CGI script, I get back a page that says 'Server Misconfigured'".

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

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 = "joe@schmoe.com";

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.