On 1/4/11 4:31 AM, John Delacour wrote:
On UNIX/ Mac OS X it also gives you the option of using a variety of perl installations. For example the Apple installation of Perl is made in /usr/bin but the default installation is in /usr/local/bin and other programs might make further installations in, say, /opt/local/bin/...
Very good point. The Perl team does at times intentionally break backwards compatability because they feel the old way was simply wrong. And it's always possible they'll do so accidentally, especially for more tricky ways of doing things. If you've got mission critical stuff running on Perl, keeping the old version around and accessible, at least for a while after the upgrade, is a good idea- and shebang makes it easy to support both as long as you need to. If you get to hacking the interpreter itself, you absolutely need a way to access the canonical version because at some point you will break the one you are hacking on. Hopefully you'll fix what you broke, but you don't want to be without Perl during that phase.
Keeping the old version around and accessible- actually, that's probably a reasonable justification for using Windows file extensions other than .pl. Associate that to whichever version is your sites primary Perl installation, and associate something else(.prl for instance) to the secondary installation. Just make sure to have a standard for which extension calls which interpreter, or things will get confusing. Including a shebang on windows for documentation purposes, so people reading the code know what interpreter is supposed to get it, is a good idea even though it's not used by the system.
-- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
