|Do you know where your variables are?|
I'm aware that the env "trick" isn't completly portable. But neither is assuming that perl is available under /usr/bin/perl. Not when so many new plattforms/operating systems enter the market these days. There are probably hundreds of companies and lonely geeks out there hacking some new, cool operating systems for their future tablets, smart(er) phones, e-book readers, industrial robots... and probably some cool gadgets not yet officially invented.
I think you miss my point. By essentially hardcoding which perl to use, you take away many possibilities. Like having a user run/test all the scripts with a different perl binary.
Of course, the user could alway call /mypath/perl somescript.pl. But that's not always possible. Especially if - say for example - a bash script starts the Perl script. And yes, you could always rewrite the scripts and such. To me, it makes more sense to just set some environment variables *once* and let the system to the actual work.
And.. another yes, most of my scripts run well on both on the system perl as well as "my own" (but i wont risk it on production systems). Testing is easy enough, i just run a bash script that changes the environment variables and i can test all of my Perl scripts on all of my installes perl binaries - without rewriting them.
So, sorry for the rant, but there currently is no 100% portable way to implement calling the correct binary for perl. But hardcoding the full path to which perl binary to use is - in my opinion - even less helpfull.
Don't use '#ff0000':
use Acme::AutoColor; my $redcolor = RED();
All colors subject to change without notice.