Re: /usr/bin/env behaviour?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 10 Nov 2008 13:31:28 -0500
    From:        "James K. Lowden" <jklowden%schemamania.org@localhost>
    Message-ID:  <20081110133128.694a4c84.jklowden%schemamania.org@localhost>

  | Not to be combative, but must it be laziness?  Is $PATH also laziness?  

The latter, not when it is sued correctly, no.   Env vars are
used to override system defaults for particular users.

  | /usr/pkg/bin/perl doesn't guarantee any particular version of perl,

No, of course not, my point was that the script should embed a
path to the version of perl it needs (assuming it exists, if it
doesn't, the script can only fail) when it is installed.

The RPATH example was not a good one - if I could set RPATH to
just "lib" and expect the library to be magically found, that
would be closer, but that's not the way it works.   The issue
isn't what is found at the location embedded (in #! or RPATH)
but that that location be exactly what the designer of the
command intended (with usually non-trivial ways to select
something different if the user really knows they need an
alternate version.)   For RPATH that's the LD_* env vars,
for #! it's just explicitly putting the interpreter on the
cmd line (before the script name...)

  | I've written any number of short Perl scripts to help someone do something
  | simple or demonstrate a technique.  The number helped by not having to
  | tweak the interpreter line far exceeds the number whose PATH included a
  | bogus interpreter.  


For that kind of script I'd submit that the correct way to run
it, is
        perl xxx.pl

quick, easy, and generally works for people who explicitly want
to run perl.   That's a different situation than a "command" that 
just happens to be written in perl, without the end user needing
to know that.

kre