> Usually "env" is used to be more portable, since /full/path/to/perl can > vary from system to system, and "env" will just search for "perl" in the > path.
Except that the path also varies from system to system, as does the version of perl installed, and the list of installed modules. Ultimately, the choice of how to invoke perl depends on your objectives. If you only ever run your code on a single system (or on identical system images), there's nothing wrong with hardcoding the path to perl. (So long as you don't mind updating the code if your system is modified to move the perl binary.) If you need portability, I'm not aware of any foolproof solution. Hardcoding the executable path will fail on a system with perl in a different location (say, /usr/bin/perl instead of /usr/local/bin/perl). If you care which version of perl is used (and face it, you probably don't test your code on every possible version of perl), you have no way of knowing which one you get. And if you use installed modules such as Tk, you have no way of knowing if they're installed in that build. (At least, not until it fails at runtime.) The only bulletproof way to ensure portability across systems is to package your perl code with its own build of perl - which, obviously, has its own costs and challenges. Good luck! Jason Elbaum _______________________________________________ Perl mailing list [email protected] http://perl.org.il/mailman/listinfo/perl
