http://www.perlmonks.org?node_id=897250


in reply to Calling the correct perl binary

Whenever the systems automatically start a Perl script, it uses the dristribution-maintained perl, whenever i start a script with my user account, it uses the perl installed in my home directory.
What's the purpose of that? For a script, there are four possibilities:
  1. It will only run with the "system" perl.
  2. It will only run with "your" perl.
  3. It will run with either perl.
  4. It won't run with any perl.
For the first two cases, using the 'env' trick is wrong - the path should be hardcoded. For the other two cases, the 'env' trick doesn't gain you anything.

So, why use it?

Note also that not every system has 'env', the systems that have it don't all have it in the same path, and that many 'env's cannot pass arguments. So, using the 'env' trick to make things more portable isn't very fruitful.

Replies are listed 'Best First'.
Re^2: Calling the correct perl binary
by cavac (Parson) on Apr 04, 2011 at 00:08 UTC

    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.

    Don't use '#ff0000':
    use Acme::AutoColor; my $redcolor = RED();
    All colors subject to change without notice.
      But hardcoding the full path to which perl binary to use is - in my opinion - even less helpfull.
      And your solution is to replace it with another hardcoded path?

      What makes you think that those new, cool platforms you are referring to have an env, and it's in the location you presume it is? I mean, if they deliver their new, cool platform, with a perl, not in /usr/bin, but elsewhere in $PATH, they may as well have env elsewhere as well.

      You seem to have a perceived problem, which you are fixing with a solution that suffers from exactly the same potential problem.