And it's not going to work, either. The shebang line is interpreted by the system, not by perl. If you really must do this try simply #!perl and then make sure the version of perl you need is the first thing in the $PATH environment var. Note that this is a security risk.

----
Reinvent a rounder wheel.

Note: All code is untested, unless otherwise stated

How is it a security risk? You mean to tell me you don't control your own path? ;)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

Actually, you cannot depend on anything in the environment, especially not the path. (Well, you can, until you start running financial applications over the web. Then, you can't.) All of that is considered tainted by -T.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Using relitive links to executables is well known to be a security risk, because you have to assume that you might not be in control of $PATH. Notice that perl running under taint mode won't let you execute external programs until you assign $ENV{'PATH'}.

----
Reinvent a rounder wheel.

Note: All code is untested, unless otherwise stated

Like hardburn said, the shebang line is interpreted by the system, not Perl. So, if you want to make sure all your systems have the right path set, I would suggest that you have a simple installation script that you run whenever you upload code. Recurse through your root code directory and replace any perl shebangs you find with the right one.

use strict;                                # duh.
use File::Find;
find ( sub {
   open IN, "< $_" || return;              # silently discard failed o
+pen
   chomp(my $firstline = <IN>);            # read in first line and
   $firstline =~ /^#!.*perl[\s\Z]/ && do { # check for a shebang
      $firstline = "#!$^X$'";              # replace with your own she
+bang
      chomp(my @nextlines = <IN>);
      open OUT, "> $_" && do {             # print the file back out
         map {print OUT $_,$/;} $firstline, @nextlines;
         close OUT;
      }
      # the next bit is a little more concise, but won't replace newli
+nes
      #$firstline = "#!$^X$'$/";
      #my @nextlines = <IN>;
      #open OUT, "> $_" && do {             
      #   map {print OUT} $firstline, @nextlines;
      #   close OUT;
      #}
   close IN;
   }, qw|
         /source/code/directory
         /another/source/dir
        |;
)
[download]

If you call this as perl thisscript.pl the special variable $^X will insert the name of your perl executable as 'perl', so run it using /var/binaries/coolest/perl thisscript.pl or wherever your executable happens to be.

Note: This was written off-the-cuff, and thoroughly untested. Use this only as a guideline and test it thoroughly before actually using it on any production code. Seriously.

Update: you probably want to write a little shell script on each system, something to the effect of

#!/bin/bash
/var/binaries/coolest/perl /usr/local/bin/thisscript.pl
[download]

That'll simplify your life a little.

Update: as I was cleaning the code a little I realized that this might actually have the happy effect of replacing the newlines in your perl files with your system's $/. I may be wrong, tho.

LAI

Don't reinvent the wheel. Use ExtUtils::MakeMaker to install scripts.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

IlyaM++ you're right, of course. I remember the documentation to ExtUtils::MakeMaker being huge, though, and assuming changing the shebang line is all that needs to be done for the install (yeah, right), I'd probably prefer to write a small script like this one rather than pull in a module and use that.

Of course, having said that, I do know that there are issues with my own snippet, and that everything it does is done better by MakeMaker, but false laziness and an eye toward getting this over with and getting back to work tell me that repackaging and redeploying stuff for every update (as well as installing MakeMaker on all the target boxen) is more work.

Update: to continue with my habit of pointing out my own fallacies, I would note that the fact that I spend a nontrivial amount of time reading and commenting on PM nodes, as well as chatterboxing or just following interesting CB conversations, should prompt me to keep my mouth shut about "getting this over with and getting back to work"...

LAI

__END__

As has been said by others before, this is not going to work, since the shebang line is interpreted by the OS; however, everyone else so far also seems to have added that it's not perl that does this, which is something I think the original author of the question already understood, since he explicitely said that they had an environment variable set to perl's location.

The real reason why it still doesn't work is that the shell is not involved in interpreting that line, either; it's done by the OS itself.

And as far as the question itself is concerned, what keeps you from having perl in a standard location? Even if you have different OSes which have perl in different places by default, you could probably just roll your own perl packages that install to /opt/local or something similar - it'd probably can't hurt to have the same perl version with the same features built in and the same modules installed on all affected machines, anyway. :)

--
mowgli

Or at the very least, symlink /usr/bin/perl to the installation of perl on that system.

I'd just like to say Nkuvu++ and "Yes, do this, just as Larry intended!" Merely upvoting this was not enough. (:

                - tye

One option that I haven't yet seen mentioned is the /bin/env trick. If your first line is

#!/bin/env perl
[download]

The system will find the perl on your path and use that. This trick was used quite a lot when standard installations did not include Perl since it allowed "non-root" users to install local copies of Perl. It allows the different systems to have different locations for the perl installation and manages to work out everything for you.

The only difficulties are:

• Security (already covered)
• Some *NIX systems put the env program somewhere other than /bin (/usr/bin/env is quite common, you could add a symbolic link on those machines?)

Having something that modifies your scripts for different locations is often a bad idea (one of the great things about Perl is that it is portable). When distributing scripts you really don't want to have to edit the script to make it function (like when sending to naïve users).