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

Michael R. Wolf MichaelRWolf at att.net
Sun Apr 15 09:05:04 PDT 2007

> I go so far as never installing or upgrading any modules under
> /usr/bin/perl.

Could you elaborate on your multi-perl stragegy?
  1.  How many Perl's do you keep?  Where?
      OS-Perl:       /usr/bin/perl
      current-Perl:  /usr/local/bin/perl

  2.  What's in your PATH?  In the she-bang line?  Where are scripts
      a. How do you guarantee that OS-Perl scripts get OS-Perl?
      b. How do you let current-Perl scripts get current-Perl?

  3.  How are updates handled?
      a. OS-Perl and subordinate modules?
      a. current-Perl and subordinate modules?

And the $64,000 question?  If your multi-perl strategy is a fix for a
broken Perl environment, what's broken about the Perl environment that
prevents you from having a mono-perl (pun not intended) environemnt?

Is the fix too academic/theoretical to be practical?  (For instance,
if every Perl script and module had some sort of "use only", all
inter-module dependencies could be checked by the computer, but it may
be too onerous a solution for the humans in the loop, or the
intricacies of maintaining multiple module versions.)

If it's academic/theoretical and practical, is it being investigated
for Perl6?  I had heard, for example, that many ISP's wouldn't install
non-core modules.  One solution to that was to have Perl ship with
*NO* modules, thus requiring a just-in-time install of *all* modules.
Such an architecture would not allow any modules to be "second class",
and would therefore require that any module could be installed with
the same mechanisms that allowed a micro-perl to bootstrap the

Thanks for the insights.  I had always assumed that "#! /usr/bin/perl"
was the "one correct solution".  I should have anticipated the fractal
quality of TMTOWTDI, applying not only to the inside of a script
(contents), but also to the outside (environment).


Michael R. Wolf
    All mammals learn by playing!
        MichaelRWolf at att.net

More information about the spug-list mailing list