Bug in #! processing - "pear broken on current"

[Garance A Drosehn]

At 3:23 PM +0200 6/10/05, Roman Neuhauser wrote:
># gad at FreeBSD.org / 2005-06-10 08:39:37 -0400:
>  >
>  > I actually have my changes written and mostly working, and right
>  > now I am reviewing the ideas to see if the design could be done
>  > any better.
>
>     Well, such env(1) *will* be useful, but recall that endless
>     debate over "#!/usr/bin/perl" vs "#!/usr/bin/env perl"?

That is a very different issue...  I do remember that debate, and in
fact I was in the thick of it.  It's just that I didn't have much
spare time to write up code for an alternate solution at the time.
Maybe someday I'll get back to that.  We *use* an alternate solution
for that issue here at RPI (instead of using `env' for it), so I know
other solutions are workable.

>     env(1) isn't very practical when you have programs out of
>     (current) path (like in SU), but that's just one small glitch
>     traded for another one.

Sure it is.  My understanding is that you want to do something like:

#!/usr/local/bin/php -n -q -dsafe_mode=0 -doutput_buffering=1

With my new `env' in place, that line becomes:

#!/usr/bin/env -S/usr/local/bin/php -n -q -dsafe_mode=0 -doutput_buffering=1

The setting of PATH is irrelevant -- or at least it is no more
important than it had been with the previous setup.  You were
never *required* to use an unqualified filename with `env'.  That
is the example you see the most, but only because people *want*
to use `env' just so that they *can* get `perl' from the PATH.

-- 
Garance Alistair Drosehn     =      gad at gilead.netel.rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA