SPUG: she-bang lines: "/usr/bin/perl" vs "/usr/bin/env perl"
Joshua ben Jore
twists at gmail.com
Sat Apr 14 20:57:09 PDT 2007
On 4/14/07, Colin Meyer <cmeyer at helvella.org> wrote:
> On Sat, Apr 14, 2007 at 12:45:33PM -0700, veritosproject at gmail.com wrote:
> > Perl now has a ./Configure option that automatically symlinks
> > /u/b/perl to /u/l/b/perl if you so choose.
> ... and thankfully, the default answer to that option is no, do not
> create a symlink from /usr/bin/perl to where ever the perl executable
> is installed (/usr/local/bin/perl by default). I've been bitten more
> than once when configuring Perl with -des. Older versions used to create
> that symlink by default.
> Most unixy OSs rely heavily on their /usr/bin/perl, and so it is best to
> leave it alone, and let the OS decide when to update it. If you upgrade
> /usr/bin/perl, but the OS is relying on some bug or feature of the
> version of Perl it installed into /usr/bin/perl, then stuff breaks. I
> have witnessed troubles from upgrading Perl on Mac OSX and various linux
> distros (at least debian and suse off the top of my head).
> I go so far as never installing or upgrading any modules under
Agreed. It's far easier to let the OS have its own copy of perl and to
maintain your own copy elsewhere. At home, this just means the default
perl is in ~/bin and that's A-OK. Scripts using /usr/bin/env will get
the proper perl regardless. Awesome.
I never break my core perl anymore, I never have to deal with problems
relating to my OS updating modules separately from me - in fact, I can
now update my own modules and perl without ever disturbing the OS.
The same principle extends to more formal environments and in fact, is
probably a best practice. The perl you depend on can vary (or *not*)
regardless of whatever your OS does or needs.
More information about the spug-list