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
Others...?
2. What's in your PATH? In the she-bang line? Where are scripts
located?
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
modules-formerly-known-as-core.
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).
Thanks,
Michael
--
Michael R. Wolf
All mammals learn by playing!
MichaelRWolf at att.net
More information about the spug-list
mailing list