Barring some special circumstances you should really be hardcoding the perl you are using.
Why, might I ask? I've scratched my head over this for several minutes and I simply can't think of a good reason for doing this, except in the unusual case where you have multiple incompatible Perl interpreters installed at the same time.
I certainly don't see how it could be a security thing. If someone's capable of adding a malicious perl binary to the $PATH of someone with superuser privileges, then the machine is probably rooted already.
And even if there are cross-platform compatibility issues that still doesn't justify leaving it up to your PATH because you can detect the system you are on and then run a hardcoded perl from within your wrapper shell script.
I'm not sure why you assume there's a wrapper shell script. I've never had any desire to use such a thing. #! /usr/bin/env perl works just fine.
Where you have a heterogeneous set of environments, the last thing you want is a fragile script that lists half a dozen or more different magic filenames, and breaks if you upgrade a system. One of the nice things about Perl is that it lets you get away from shell scripts, which are a nightmare to make portable!
And that's without even getting into the situation I'm commonly in, where I don't know what systems my scripts are going to run on. Sure, I could write a fragile shell script, and then when someone wants to run the script on Cygwin I could add another special case, and then when someone wants to run it on Solaris I could add yet another special case... or, you know, I could just put #! /usr/bin/env perl and it would just work on all the most common platforms, letting me reserve special-case handling for actual special cases.
In reply to Re^2: #!/usr/bin/perl vs. -*- perl -*-
by Porculus
in thread #!/usr/bin/perl vs. -*- perl -*-
by why_bird
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |