Wrapper for invoking perl

How do I invoke perl using a wrapper kind of script so that migarting to a newer version of perl does not affect existing script开发者_StackOverflow中文版s?

---

What exactly is the scenario you envision?

That you have a "perl" binary which you may change from Perl 5.8 to say 5.10?

The easiest solution to that is to have your shebang line point to a version-specific Perl.

There are two flavors of this approach - one has the version-specific softlink, one has a "current Production version of Perl" one.

$ ln -s /usr/local/perl5.8/bin/perl /usr/local/bin/perl5.8
$ ln -s /usr/local/perl5.8/bin/perl /usr/local/bin/current/perl

$ cat my_script.pl
#!/usr/local/bin/perl5.8
# This script is REALLY hard coded to 5.8
...

$ cat my_script2.pl
#!/usr/local/bin/current/perl
# This script is hard coded to 5.8 for now, 
# but can be easily switched to different Perl version as part of MASS migration when ready
...

This way, your script is ALWAYS guaranteed to use Perl 5.8, even if you eventually upgrade to 5.12 and "perl" binary will start calling perl 5.12 as far as PATH goes.

This approach ALSO makes upgrading easier - simply change the softlink to point to new Perl binary when you wish.

---

It is highly unlikely that backwards-compatibility for documented features will be broken in perl 5.

An insurance would be keeping a copy of the old perl binaries.

---

It's not entirely clear which of these you want, but:

• If you DO want to always run the first perl in $PATH, so that you'll get upgraded versions transparently, you should use #!/usr/bin/env perl

• If you DO NOT want the version you're running to change out from under you, you can install exactly the perl you want at a location other than /usr/bin/perl (since that's managed by your OS vendor, not by you, so it could change when you don't want or expect it to) and start your Perl with #!/path/to/my/custom/perl

• In the latter case, you could still use #!/usr/bin/env perl and manipulate your $PATH so that the perl you want to use will be the first one found. This is handy if you want to use different builds of perl at different times, such as for testing against different versions.