Laurence’s Blog

I, personally, find it really irritating when a device (like, say, an IPhone) uses a browser (like, say, MobileSafari) which behaves in a contradictory manner (like, say, displaying the contents of <noscript></noscript> tags and running the scripts embedded in the page perfectly). Grrr.
</venting>

The first thing I do whenever I start a script is to add the #! line. When writing Python I have always written ‘#!/usr/bin/env python’ and when writing Perl ‘#!/use/bin/perl’. I suspect this stems from using systems where it was commonplace to have multiple versions of Python installed (at the time, 2.3 and 2.4) but only a single version of Perl (5.8.8).

This has always worked fine for me because 90% of the time there is only one version of Perl, and it(or a link to it) is at /usr/bin/perl. I discovered today, however, a situation where there are multiple versions of Perl and the one I want is not at /usr/bin/perl.

I recently purchased a 12" PowerBook running OSX 10.5. I needed some development libraries installed and MacPorts seemed to offer the quickest, easiest and most maintainable route to install them. So I installed the libraries I needed and one of them pulled in the MacPorts version of Perl. I then spent the next 30 minutes, or so, trying to figure out why my script would not run but manually invoking the parts causing it to fail with ‘perl -e’ worked fine. It turned out (as you have probably guessed by now) that my script had a #! line using /usr/bin/perl (the OS provided version) whilst `perl` was using /opt/local/bin/perl (the MacPorts version) due to path precedence. Changing the #! line to ‘#!/usr/bin/env perl’ made the script run properly.