Re: Bug in #! processing - "pear broken on current"
From: Garance A Drosehn (gad_at_FreeBSD.org)
Date: 06/10/05
- Previous message: Dag-Erling Smørgrav: "Re: Bug in #! processing - "pear broken on current""
- In reply to: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Next in thread: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Reply: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Reply: Jeremie Le Hen: "Re: Bug in #! processing - "pear broken on current""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 10 Jun 2005 08:39:37 -0400 To: Roman Neuhauser <neuhauser@sigpipe.cz>, Florent Thoumie <flz@xbsd.org>
At 12:48 PM +0200 6/10/05, Roman Neuhauser wrote:
># flz@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.
However, I do agree that the previous behavior could be very useful
in other situations. I will soon have a version of `env' which will
provide all the benefits that used to happen due to the previous
parsing behavior. In fact, it will be even more flexible and support
even more options than the previous parsing behavior did. And I think
I can even define it in such a way that other operating systems could
pick up these changes to `env' (if they wanted to), and enjoy the same
flexibility. And more important to me, I could recompile this new
`env' on other operating systems, and at least *I* would have those
benefits on all platforms I work on!
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.
-- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Dag-Erling Smørgrav: "Re: Bug in #! processing - "pear broken on current""
- In reply to: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Next in thread: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Reply: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""
- Reply: Jeremie Le Hen: "Re: Bug in #! processing - "pear broken on current""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: My disk I/O testing methods for FreeBSD 5.3 ...
... Are there any outstanding code changes that will help improve ... > the performance
and questions mailing lists under the title " FreeBSD ... > Operating Systems tested:
... > the default installation options as possible with no special tuning. ...
(freebsd-performance) - Re: My disk I/O testing methods for FreeBSD 5.3 ...
... > the performance and questions mailing lists under the title " FreeBSD ...
> Operating Systems tested: ... > the default installation options as possible
with no special tuning. ... > as possible test the disk I/O performance on a range of
hardware, ... (freebsd-performance) - Re: [ANN] Ltk - The Lisp Toolkit
... > have DO-EXECUTE heavily conditionalized for various operating systems, ...
> it might be better to simply eliminate START-W altogether, ... for special purposes
without changing the Ltk source. ... from a FreeBSD user, as I have no FreeBSD experience
of myself. ... (comp.lang.lisp) - Re: Memory mannagment
... The memory is divided into segments is that what it means? ... Tell me anything
else interesting to know about memory mannagment, ... I am studying freebsd but
sometimes I am ... Many of your questions can be possibly answered better by taking a computer
architecture and/or operating systems course, as many of the questions and ideas you have most
likely apply to real-time operating systems, including Linux, OSX, Solaris and even Windows, not just
FreeBSD. ... (freebsd-questions) - Simplifying FreeBSD Installation
... I have read a few posting regarding the FreeBSD installation procedure. ...
Then getting the three computers to actually network together is another ... Greater effort
should be put into getting the operating systems ... (freebsd-questions)