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

[Roman Neuhauser]

# gad at FreeBSD.org / 2005-06-10 08:39:37 -0400:
> At 12:48 PM +0200 6/10/05, Roman Neuhauser wrote:
> ># flz at xbsd.org / 2005-06-10 10:06:46 +0200:
> > > On Jun 10, 2005, at 8:24 AM, Roman Neuhauser wrote:
> > > >
> >> >    The pear people have hacked around the other OS's limitations.
> >> >
> >> >    This change makes FreeBSD lose one small but fine competitive
> >> >    advantage over other unix-like systems. Pity.
> >>
> >>     FreeBSD needed special handling, no it doesn't anymore.
> >>
> >>     I'm not sure that's losing a *competitive* advantage.
> >
> >    The previous behavior in FreeBSD allowed me to use things on
> >    the shebang line that weren't possible in e. g. Linux, and I
> >    enjoyed it, because it saved me from various hacks. Aiming for
> >    the lowest common denominator means losing useful features. One
> >    reason to prefer FreeBSD less.
> 
> Well, there's more than one way to get the job done, and it is much
> too early to be wailing over the end of FreeBSD due to this change.
> The recent change to the kernel-level parsing pretty much has to stay,
> or FreeBSD users will continue to run into some other problems which
> happen *only* on FreeBSD.  The parsing that we used to do was meant
> to be helpful, but in some situations it was completely wrong.

    But it was completely right in the pear case, and far more useful,
    which is what I'm whining about.
 
> <about patches for env(1)>
> 
> I think these changes could even be MFC'ed to 5.x (and 4.x, if needed),
> and then a single #!-line could be written which would work on all
> those systems.  I'm not sure that MFC-ing would be worth it, though.
> 
> 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.
> Now I don't know if I can get everyone else to agree that my ideas
> are wonderful, of course, but it sounds like I might get a 'yes' vote
> from you.  :-)    More details soon, and then we shall see.

    Well, such env(1) *will* be useful, but recall that endless debate
    over "#!/usr/bin/perl" vs "#!/usr/bin/env perl"? 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.

    To sum it up: why, yeah, if you have a recipe to coerce existing
    programs into the new model, go ahead. Make sure it's noted
    somewhere port contributors will find it.

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991
_______________________________________________
freebsd-arch at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"