can't get perl running

[bbxrider]

i'm running apache 2.2.4, under winxp pro, been trying to get perl running for a few hours now
i installed perl on a g: drive, g:/usr, with the lastest active perl msi, perl -v runs from the command line
eventually i want to run at least one app, uber upload, that is typically configured to run .pl scripts from the std apache cgi-bin directory.
but for now and to test, i created the hello.cgi script, to run out of a virtual host directory
#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "hello world";

in my .conf i have the directory directives and no other (like to override other dirs at say at htdocs)
<Directory />
Options FollowSymLinks +ExecCGI -Indexes
AllowOverride None
Order deny,allow
Deny from all
Satisfy all
</Directory>

in the virtual host log i'm getting
-client denied by server configuration: C:/apache2/htdocs/myVirtDir/hello.cgi
and i get a 403 forbidden in the browser

can somebody please try to decipher this to help me get a basic script to run and hopefully suggest what i might need to change beyond that to have scripts run out of the std apache cgi-bin directory
bob

[jdMorgan]

First of all, remove the "Deny from all" and replace it with "Allow from all" for now; You don't want to be fighting multiple problems all at once. Get PERL running, then re-apply your directory access restrictions.

Then you'll need to properly declare the path-to-PERL in the script header... I'm not actually sure how you'd do that if PERL is located on a different drive, unless you symlink it in the OS. But Windows doesn't support SymLinks, so that's not an option. But at any rate, the path in "#!/usr/bin/perl" must resolve to the PERL interpreter's executable file directory.

Jim

[bbxrider]

ok great jd, i got the allow and path to perl is g:/usr....etc, and the .cgi script runs. but now back to the original task, an application that invokes a .pl script. when i try to run the app with the .pl in the std setup cgi-bin, in firefox i get 'firefox doesn't know how to open this address, because the protocol(c) isn't associated with any program' and no error msg in the log
if i put the .pl in the virtual dir root where i can now run hello.cgi, and invoke it with uber_upload.pl?about=1, which is way to test it, i get an internal server error msg in the browser and in the error log i get 2 errors
(OS 3)The system cannot find the path specified. : couldn't create child process: 720003: ubr_upload.pl
(OS 3)The system cannot find the path specified. : couldn't spawn child process: C:/apache2/htdocs/joomla/ubr_upload.pl
i copied hello.cgi to hello.pl and that runs ok, so i guess i'm stuck now with some problem in the application script? because it seems i can now successfully run perl scripts that don't have some bug or misconfiguraton thing, yes?

[jdMorgan]

Check the server response headers with the Live HTTP Headers add-on for Firefox, and make sure that your script is outputting the correct MIME-type for whatever content it produces, e.g. "Print('Content-Type: text/html\n');" before outputting anything else.

Also, not sure if it was a typo here, or in the config, but I wouldn't expect it to be able to find "/ubr_upload.pl" if "uber_upload.pl" was intended...

Jim

[bbxrider]

thanks again for the follow up
i hope you or somebody can follow all this
first running the scripts, i can't run scripts directly out of the apache cgi-bin (c:/apache2/cgi-bin) its just not recognized, i can run .pl scripts, where ExecCGI is enabled in the virtual host, in the root of some domain i'm using, so [somedomain.com...] runs, some i'm thinking, if ubr_upload.pl can actually run, i can also invoke it with [somedomain.com...]
now the mime-type, the live http headers indicates firefox (or any browser?) can run (if i understand the following):
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
and
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
searching the ubr_upload.pl script for 'content-type' it uses either
'content-type:text/html; charset=utf-8' or just 'content-type:text/html;' when creating the test page using the ?about=1 parameter

so...... it looks like the content type is covered for this script if i'm reading the http header info right and the way the script is specifying the content type. so this part seems ok, yes?

one thing i noticed is ubr script uses
use strict; # Insert whipping sound here
use CGI::Carp 'fatalsToBrowser'; # Dump fatal errors to screen
use CGI qw(:cgi); # Load the CGI.pm module
from reading on this, the cgi.pm is used due processing form data. perhaps my configuration isn't giving access to cgi.pm. i can't find it anywhere on my system, not in the perl installation or in apache.
could that be the problem?

[bbxrider]

thanks for the help here, turns out there were problems with my shebang line, and the various use CGI options, also found the ScriptInterpreterSource directive, which seems a good alternative to the potential problems and maintenance issues with the shebang lines.