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.