#!/usr/bin/perl\r\n
[download]

it will be looking for a file called 'perl\r' in /usr/bin. Whereas

#!/usr/bin/perl -wT\r\n
[download]

Do a quick 'hexdump -c filename' to see if this is the case.

Update: A bit more about the time I got bit by this.... I had a jr sysadmin working under me put a new 'ifcfg-eth0' to a soon-to-be-production machine with a buch of '\r's in it. It looked something like:

DEVICE=eth0\r
IPADDR=xx.xx.194.149\r
NETWORK=xx.xx.194.128\r
NETMASK=255.255.255.128\r
BROADCAST=xx.xx.194.255\r
[download]

When we cycled the machine right before deploying it, we lost remote connectivity (it was trying to configure the device 'eth0\r'. We had to go down to the colocation facility and debug if from there. The error message on the screen was 'eth0 no such device' (i.e 'eth0\r no such device') which wasn't particularly helpful. After cycling the machine numerous times and swapping out some hardware, someone noticed that emacs was labeling it as a DOS file. A quick 'perl -pi -e "s/\r//g" ifcfg-eth0' fixed it.

-Blake

#!/usr/bin/perl -wT\r\n Will actually work.

That's my guess. I just verified (on Linux and FreeBSD) that a \r won't screw up the #! line if it appears after a command line option. I assume the kernel stops scanning for the path to the executable as soon as it hits whitespace, and that the presense of command-line options are sufficient to prevent the \r from being considered as part of the path of the executable.

'perl -pi -e "s/\r//g" ifcfg-eth0'
For the life of me, I could never remember the command-line syntax-ish way of doing things like that. I thank you Blake, you just made my job of moving my mod_perl stuffs around. I'll go about figuring out what -pi -e means, but for now.. it works. :)

_14k4 - perlmonks@poorheart.com (www.poorheart.com)

Your shell was trying to run an interpreter called "perl\r". If you want a quickie demo, create a symlink in the directory where the script resides with the following command:

ln -s `which perl` `echo -ne "perl\r"`
[download]

Now change the shebang line to invoke perl via the symlink in the current directory, being careful not to remove the carriage return:

#!./perl
[download]

Invoke your script and the shell will exec perl via the "perl\r" symlink without complaint.

Update: I should add the magic incantation to remove the nasty symlink:

rm `echo -ne "perl\r"`
[download]

which perl

to see which the full path to the perl binary for 'perl somescript.cgi'

try running the script through 'od -c somescript.cgi'. od is essentially a hex dumper, and you should be able to spot if there is anything funky on the shebang line.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

Gary Blackburn
Trained Killer

That has nothing to do with the problem.

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

This is Ovid posting as He Who Must Not Be Named. No need to XP whore for a 'thanks'.

blakem wins the non-existent prize for fastest answer (he even beat some of the mailing lists I'm on).

We've tracked down what happened. Seems that some sent a zipped file to our server via FTP instead of just sending the plain text file. By extracting the file directly on the Linux box, the DOS line endings were preserved (most FTP clients can convert them for you).

Yet another piece of information for my clue box :)

Cool, glad to know that it helped... Something just clicked at "I'm relatively new to Linux" on my second reading. It reminded me of the 'eth0\r' problem, and I *know* how frustrating tracking that one down was. If it shaved a few minutes off of the pain that banging your head against the keyboard brings, I'm happy to have been of service. ;-P

-Blake