[Israel.pm] Perl version migration

Mikhael Goikhman migo at homemail.com
Sun May 2 05:14:20 PDT 2004


On 02 May 2004 14:57:15 +0300, Jason Elbaum wrote:
> 
> Sure, we can install new Perl alongside old Perl - that's what we have 
> now for 5.6 (for example). The annoyance is that scripts which need a 
> particular version have to point to it explicitly ( 
> #!/usr/local/bin/perl5.6.1 ) or they'll always get 5.004. On the other 
> hand, if we just install new perl in place of old perl, we risk 
> disturbing  old scripts which may rely on features of 5.004 without even 
> knowing it. And it's probably not realistic to review all our existing 
> scripts and test them for transitioning to new versions of Perl.
> 
> So is it *ever* possible to get out of this trap? Or will we be stuck 
> forever with default perl at version 5.004, and new versions selected 
> explicitly by the name of the perl executable?

One of the correct solutions to this kind of problems is to use wrapper
scripts on unix.

Remove any real "perl" executable from your $PATH, create just one wrapper
/usr/bin/perl (or /usr/local/bin/perl) that may look like:

  #!/bin/sh

  case "$PWD" in

    /data/new_site/*|/opt/new_perl_module/*)
      exec perl5.8.3 "$@"

    /data/cur_site/*|/opt/cur_perl_module/*)
      exec perl5.6.1 "$@"

    *)
      exec perl5.00401 "$@"

  esac

Then all scripts may just always have "#!/usr/bin/perl -w" as the first
line and be automatically dispatched to the correct perl. And of course
you may use a different condition ($USER, $REMOTEHOST), not just $PWD.

This solution requires root permissions, but it is not a problem for you.

Regards,
Mikhael.

-- 
perl -e 'print+chr(64+hex)for+split//,d9b815c07f9b8d1e'



More information about the Perl mailing list