If I download code and install it via Makefile.PL or Build.PL, then the perl that runs the .PL gets to be the perl that runs the resultant code. If I download code and it just wants to "be", it's either an all-in-one version of ack, or it's probably not something I want to use anyway.

I have a bunch of perls installed in ~/perl/$version/bin - and I use Gentoo's eselect with a custom-written (shell) module that creates ~/bin/lperl ("l" for "local") as a hardlink to the current perl (and lperldoc and lcpan). If I write a script I want to use a particular version, I put in "#! $myhomedir/perl/5.12.2/bin/perl" at the top, and I'm done. If I want to test against a bunch of perls, I use "#! $homedir/bin/lperl", and then I can just swap the hardlink ("eslect lperl set 5.12.2" - tab completion works here).

In $work-related code, I absolutely must use perl 5.8.8, which I'm none-to-happy with, but I digress. I actually export DEV_PERL="~/bin/perl5.8.8" (which is also a hardlink over to the perl 5.8.8 in ~/perl/5.8.8/bin), and then I put code like this at the top:

# -*-perl-*-

# Allow people to override the perl location with a real perl of the r
+ight level
eval 'exec ${DEV_PERL:-/usr/bin/perl} -S $0 "$@"'
   if 0;
[download]

This will default to being run by the shell, which will ignore the first three lines, see the next line as "eval <code>" and eval that code, which is to exec (replace itself with) perl, with the same parameters as before (the -S tells perl it may need to check PATH - never tested if that's really needed or not). Perl comes along, ignores the first three lines again, sees the eval, but then keeps going to the semicolon, and sees it's an "if 0", and should pretty much eliminate that line during compilation. The shell never sees the rest of the code.

So, you can see I use multiple approaches. Because I've not found any one approach to be obviously better in all circumstances, but different needs will result in different solutions. Here is where a good understanding of how your operating system figures out how to run a script comes in handy, plus some decent shell knowledge that can give you more options.

Note that you should assume /bin/sh is bourne shell. Any other assumption is dangerous. Even some ksh's and bash's operate a bit differently when they see they're called as "sh" instead of "ksh"/"bash".

(PS - you can't actually use $myhomedir in the #! line - it's just a shortcut for my home directory, if you copy my ideas, you'll have to modify for your home directory.)