Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic


by perlisfun (Sexton)
on Mar 13, 2003 at 15:57 UTC ( #242722=perlquestion: print w/replies, xml ) Need Help??
perlisfun has asked for the wisdom of the Perl Monks concerning the following question:

We have a lot of perl script to be saved in our version management tool. perl location is varied from host to host. We have an environment variable $var set to lead to perl location. when i put '#!$var/bin/perl' in the first line of the script. It does not work. Do you have any idea to make it work? Thanks, Perlisfun.

Replies are listed 'Best First'.
Re: #!$var/bin/perl
by sschneid (Deacon) on Mar 13, 2003 at 16:06 UTC
Re: #!$var/bin/perl
by hardburn (Abbot) on Mar 13, 2003 at 16:03 UTC

    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

Re: #!$var/bin/perl
by LAI (Hermit) on Mar 13, 2003 at 16:39 UTC

    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 |; )

    If you call this as perl the special variable $^X will insert the name of your perl executable as 'perl', so run it using /var/binaries/coolest/perl 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/

    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.



        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"...


Re: #!$var/bin/perl
by mowgli (Friar) on Mar 13, 2003 at 17:09 UTC

    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. :)


      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
Re: #!$var/bin/perl
by hawtin (Prior) on Mar 14, 2003 at 10:04 UTC

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

    #!/bin/env perl

    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).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://242722]
Approved by particle
[1nickt]: Isn't it YAPC::NA too?
[Corion]: Yes, but I think there's not that much overlap in our audiences ;))
[1nickt]: Sheesh, I would have thought they would be satellite-linked somehow!
[1nickt]: Who's writing all the code this week, then?

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2017-06-27 20:56 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (613 votes). Check out past polls.