Because Perl is designed to be portable, it's often a matter of very specific OS features that cause the issues. Does your program compile? Do you have the right version of Perl? Did you remember to change the shebang line to point to your Perl compiler (boy, I can't tell you how many times I've been bitten by that bug).

If you can answer some of those questions and post those answers here, we can give you much better feedback -- but please don't post 1,000+ lines of code :)

Also, check here for a list of related Perlmonks nodes.

You can also check out this perl.com article which deals specifically with portability issues.

Cheers,
Ovid

Well... No error messages. It just comes up blank and says "Done" at the bottom, but doesn't display the web page that it is supposed to, as it does on the unix box. I'm wondering if it may have to do with file locations - / vs. \. I changed the shebang line, but don't know if it's right. Do I need to specify a drive as well as directory? The perl compiler and the site are on different drives. I've looked EVERYWHERE on the web and can't seem to find a simple "Guide to Converting Perl for Unix scripts to Perl for Windows." Thanks for your reply and any other suggestions you might have, Elissa Joan

Web page! Ah... this sounds like we may have CGI problems to consider.

In the shebang line, you probably need to explicitly state the location of your Perl compiler, including the drive. Your Web server might find Perl if it's in your path, but I wouldn't be willing to place bets on it. On my local box (Win98, ActiveState, and Apache), I found that if I change my shebang line from #!C:/perl/bin/perl.exe -Tw to #!perl/bin/perl.exe -w, it still runs. However, C:/perl/bin is in my path, so that may have something to do with it.

Don't worry about the slashes with Perl. Perl uses the forward slash as a path separator, despite Windows using the back slash. This allows for greater portability.

What do you mean your script says "Done" at the bottom? That sounds to me like you are running it through a DOS window instead of a browser. If so, are you using the object-oriented style of CGI.pm (are you using CGI.pm)? If not, you can't pass name=value pairs through on the command line (used when you debug from the command line) which may possibly interfere with your script's execution (i.e. it can't process parameters that it doesn't receive). Another issue: sometimes CGI scripts are required to be run through a browser (they may be checking whether or not you've properly authenticated, for example). If so, you'll need to find where such issues arise and develop some debugging routines to deal with this.

Incidentally, since it sounds like you are running it through a DOS window, I suspect you are invoking it with something like perl somescript.cgi. If so, you should be getting an error message saying Too late for "-T" option at somescript.cgi line 1. If not, you're not using taint checking. That's probably not going to stop your script from running, but it will be a huge security hole.

Lastly: if you are running the script through the command line, I strongly suggest that you learn how to use the debugger. You may hate it now, but it will quickly become one of your best friends. If you learn to use it, you will probably find your problem immediately.

Cheers,
Ovid

#!/usr/bin/perl -w
use strict;
use diagnostics;
[download]

You'll probably end up with pages full of things to check. Log them to a file and do what they recommend.

Thanks. Cool. So here's what I got: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Global symbol "$q" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 132. Global symbol "$sess_id" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 134. Global symbol "$usr_name" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 136. Global symbol "$password" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 137. Global symbol "$PATH" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 140. Global symbol "$MAIN_PANEL" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome.pl line 150. Global symbol "$TEMPLATE" requires explicit package name at e:\inetpub\awesomelibrary.net\cgi-bin\awesome

Aha. What you need to do is tell Perl that you want to use these variables. Generally, that's done something like this:

#!/usr/bin/perl -wT     # or #!c:/perl/bin/perl -wT

use strict;
my $q;
my $sess_id;
my $usr_name;
my $password;
[download]

and so forth. If you're familiar with scoping rules in another language, you'll find that Perl is pretty similar.

COOL! I'm actually making progress. Disregard last message... got through that one and working through some more warnings and the page half-loads now.

Just two quick notes about the #! line and Win32. On Win32, the path in the #! doesn't matter so it is good form to set it to the official "#!/usr/bin/perl -w". On Win32, the "-w" (and/or other switches) in the shebang line does matter so you don't need to run "perl -w script" to get warnings enabled.

Not so. I am running Apache 1.3.9 under Windows 98 on my laptop, and it requires a valid path. I ended up installing perl into the /usr directory so that the scripts would not have to change between the actual unix server, my test workstation, and my laptop. So, if the server is Apache, you have to have the path. My first target would be server log files (browser or not) to determine what exactly went bad. That will allow you to start pin-pointing the problems.