SPUG: she-bang lines: "/usr/bin/perl" vs "/usr/bin/env perl"

[Joshua ben Jore]

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
> /usr/bin/perl.

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.

Josh