The problem here is, "It works when explicitly invoked with perl, but fails when launched as an executable." The reason in this case appears to be a DOS line ending causing a carriage return to be seen as part of the interpreter's name.

We don't know that for sure just yet... it *could be* a DOS line ending problem, but it *could be* a multiple perl version issue. We still haven't heard back from Ovid on whether any of the suggestions mentioned solves the problem.

Basically, he needs to use "od -c somescript.cgi" to see if the first line shows a \r on the first line of the script, and he needs to try running from the command line both "/usr/bin/perl somescript.cgi" and "/usr/local/bin/perl somescript.cgi" to make sure they both produce the same results.

In any the case, lets not get jumpy about it. All the suggestions so far are good ones.

Zucan

Adding command line switches (eg warnings) will fix a DOS line ending problem but won't fix a multiple Perl version issue. Therefore it is not a multiple Perl version issue.

But note that using od is overkill. On Linux if you vi the file, you will see carriage returns as ^M. Also note that rather than guessing where an alternate Perl version might be, you are better off running:

which perl
[download]

or by running the script:

use Config;
print Config::myconfig();
[download]

in various ways.