And for the life of me can't figure out what's going on.
Don't worry, you're not the only one who's been bitten by this silly feature (as pointed out by davido).
Another "favorite" one of mine is this (see perlrun):
"If the #! line does not contain the word "perl", the program named after the #! is executed instead of the Perl interpreter. (...)"
<rant>
Let's say you wanted to write a wrapper something like this
#!/bin/sh
eval 'PATH=/usr/local/bin:$PATH \
exec perl -x -S $0 "$@"'
if 0;
#!perl
print "this is $^X, version $]\n";
with the idea being that your preferred perl (/usr/local/bin/perl) is being used if found, or else some other (possibly older) one on the default PATH. Also, you'd like people to be able to call the script via
/path/to/some/other/perl script.pl
so they can directly use whatever perl they have in some non-default location. Similarly, your Windows users should be allowed to simply say
perl script.pl
(which is why you've put the eval '...' if 0; around the shell code)
The first part works fine, i.e. if you call the script via the shebang/shell wrapper, you'd get as expected
$ ./script.pl
this is /usr/local/bin/perl, version 5.012002
but if you try to use some other perl, e.g.
$ /usr/bin/perl -v
This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
$ /usr/bin/perl script.pl
this is /usr/local/bin/perl, version 5.012002
you still get the same perl version as before! And even worse, your Windows users would simply get
>perl script.pl
Can't exec /bin/sh at script.pl line 1.
Why is that? Well, Perl tries to be helpful and - as it doesn't see "perl" on the first #! line - calls /bin/sh for you...
Sure, you can make it work by saying
perl -x script.pl
but what mere mortal user would think of doing so?
</rant>
|