The answer is in $^X.

>perl -le "print $^X"
c:\Progs\perl588\bin\perl.exe
[download]

That was going to be my original answer, until I continued reading that section in perlvar and saw this text:

Because many operating systems permit anyone with read access to the Perl program file to make a copy of it, patch the copy, and then execute the copy, the security-conscious Perl programmer should take care to invoke the installed copy of perl, not the copy referenced by $^X.


---
It's all fine and dandy until someone has to look at the code.

The warning makes no sense in that situation. It tells you to use a copy of Perl that's known to be safe instead of relying on $^X, while the OP's problem is that he doesn't know where his Perl is located.

The warning applies to the method used in your solution too. In fact, it applies to all answers to the OP's question other than those that match the pattern "I talked to your service provider and they told me to use the Perl located in XXX."

Furthermore, if the OP made a copy, he probably wants to use that copy (especially if he patched it).

The usual case for using $^X is to spawn a subprocess. The warning applies to launching child processes from setuid scripts (or code that might find its way into one).

This functionality has been portably implemented by Per Einar Ellefsen.

See File::Which for the details.

#!/usr/bin/perl

use strict;
use warnings;

use File::Which qw(which where);

my $path = which('perl');
my @paths = where('perl');
[download]

which perl
[download]

Well, the Apache installation for Windows is a bit different. It is not looking at file associations. If you screw up the shebang even if it is Windows, it will not run correctly.

use Config;
my $perl_with_path = $Config{perlpath};
[download]

my $p;
for (split /,|;/, $ENV{PATH}){
      m/\Wperl\W/i and $p=$_
    };

print qq[===$p==\n]; # $p contains the path to perl
[download]

Update:Ignore this drivel. Use ikegami's (++) correct answer below.

#! perl
[download]

As long as perl is found in the path, it'll work. I'm not convinced it even needs to be in the path. An incorrect path will not work, Apache won't like it.

I am writing an automatic installation, not a manual installation.

I would like a programmatic solution because I will be giving the installation to people who may or may not have the expertise to figure out where the interpreter is located and the application maybe in Windows or UNIX so it has to be flexible.

in that case your writing a ".exe" right?, then you gotta get the ".exe" to search the file system for the appropriate file, then include it in the installed file, simular to when some programs instal, they go off and look for the nessary system files they need (i.e. fonts,sound,drives etc) then add them to the pre-install file, then once all found and no errors, instal the pre-install file! so, you gotta find the general folder, then the ".exe" has to include it in the instal!

#!/usr/bin/env perl
[download]

As far as I know env should be always in the same place.

I heard that it's not in the same place on all systems. It definitely does not exist there in Windows (which is the important part of the question, since perl is probably in /usr/bin on the unix box).