in reply to how to invoke a different perl interpreter based on user ENV variable

Would something like the following work? This is entirely untested, so don't take my word for it.

#!/usr/local/OurPerl/bin/perl -w exec $ENV{TEST_PERLROOT}, $0 if $ENV{TEST_PERLROOT}; # insert code here
  • Comment on Re: how to invoke a different perl interpreter based on user ENV variable
  • Download Code

Replies are listed 'Best First'.
Re: Re: how to invoke a different perl interpreter based on user ENV variable
by tilly (Archbishop) on Feb 16, 2004 at 16:57 UTC
    This solution has the following serious shortcomings, listed in order of increasing seriousness:
    1. It isn't in a BEGIN block, so will not protect you from trying to load modules that aren't there.
    2. You lose @ARGV.
    3. It gets into an endless loop - you need to test whether you have the *right* version of Perl, else when you get the right one, you will keep on thinking that you have the wrong one and exec again.

      I just finished realizing #2 and #3 myself and reposted to fix those. My reposted version was enclosed within a BEGIN block to begin with but I removed it because I didn't really see the need for it. Thanks for mentioning that one for me :)

Re^2: how to invoke a different perl interpreter based on user ENV variable
by Anonymous Monk on Feb 16, 2004 at 16:59 UTC

    Of course that wouldn't work, silly me. You'd just be continually exec'ing, without passing arguments as well. You'd need to stretch it out with more code:

    #!c:/perl/bin/perl -w if (defined($ARGV[0]) and $ARGV[0] eq 'skip') { shift @ARGV; } else { exec $ENV{TEST_PERLROOT}, $0, 'skip', @ARGV if $ENV{TEST_PERLROOT}; } print 'My arguments: ', join(', ', @ARGV), $/;

      excellent. this works. I'll also look at par. I wanted to avoid having users messing with their PATH unless that was the last option. Thanks to all! - bill
Re: Re: how to invoke a different perl interpreter based on user ENV variable
by billbabcock (Acolyte) on Feb 16, 2004 at 17:02 UTC
    I tried stuff along that line first, to no avail - although I did get some variant of this to work if I invoked the script directly via the shellm, e.g.: sh ./foo.pl. Unfortunately, that's not practical as some of these scripts are cgi, others called by other progs.
      ah - I replied before seeing the other replies. Let me look that over. Thanks - bill