In message <[EMAIL PROTECTED]>, Corinna Vinschen writes
:
>On Jan 29 01:32, Peter Seebach wrote:
>> In message <[EMAIL PROTECTED]>, Larry Hall writes:
>> >I provided my suggestion, which Peter followed. It's the ash maintainer
>> >that has the final word on what, if anything, happens next and/or
On Jan 29 01:32, Peter Seebach wrote:
> In message <[EMAIL PROTECTED]>, Larry Hall writes:
> >I provided my suggestion, which Peter followed. It's the ash maintainer
> >that has the final word on what, if anything, happens next and/or what
> >the criteria should be.
>
> Just a follow-up on this:
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>I provided my suggestion, which Peter followed. It's the ash maintainer
>that has the final word on what, if anything, happens next and/or what
>the criteria should be.
Just a follow-up on this: I'm doing an article on "portable scripting",
so
At 09:57 PM 12/31/2003, Shankar Unni you wrote:
>Larry Hall wrote:
>
>>Performance of configure scripts was abysmal when /bin/sh == /bin/bash.
>
>Umm, ash+getopts != bash. I think this is an apples-and-oranges comparison. Certainly
>ash (in any form) would be much faster than bash - no argument th
Peter Seebach wrote:
> >Or perhaps at the time the change was made fork/vfork was not nearly as
> >optimized as it is now.
>
> That wouldn't give ash any special advantages over bash; indeed, it would
> seem to favor shells with *more* builtins.
It could make a huge difference if bash used fork(
In message <[EMAIL PROTECTED]>, Brian Dessent writes:
>Peter Seebach wrote:
>> Note also that, on the gcc configure script, the difference between /bin/sh
>> and bash is maybe 5 seconds on a script that takes nearly 3 minutes. It's
>> hard for me to imagine this being the source of the word "abysm
Peter Seebach wrote:
> Note also that, on the gcc configure script, the difference between /bin/sh
> and bash is maybe 5 seconds on a script that takes nearly 3 minutes. It's
> hard for me to imagine this being the source of the word "abysmal"; I'm
> assuming something else was changed. Maybe di
In message <[EMAIL PROTECTED]>, Shankar Unni writes:
>I guess the big question now is: how would Peter "prove" to anyone's
>liking that ash+getopts ~= ash-getopts in performance (and nowhere near
>"bash")? Is there some acceptance criterion that anyone's willing to
>spell out? PTC is fine, but
Larry Hall wrote:
Performance of configure scripts was abysmal when /bin/sh == /bin/bash.
Umm, ash+getopts != bash. I think this is an apples-and-oranges
comparison. Certainly ash (in any form) would be much faster than bash -
no argument there, and I don't think anyone's advocating linking sh t
>> % cygcheck --version
>> cygcheck version 1.30
>> System Checker for Cygwin
>> Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
>> Compiled on Feb 8 2003
>
>FYI, this doesn't tell us anything about the version of Cygwin
D'oh!
--Blair
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Would you be willing to take this a step further and provide some
>configuration timings for some of the existing Cygwin packages? Of
>particular interest would be the larger packages, like binutils, gcc, and
>gdb. If these have favorable resul
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Indeed. That it would be. Of course, like I said, lot's of things have
>changed so the results today don't necessarily conflict with the findings
>of yesteryear.
It's possible. My guess is that the big improvement was nuking the history
and j
At 06:46 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Peter Seebach writ
>es:
>>Can we just kill this now? Take out the "-j", leave the support for getopts
>>in the shell, and all the shell scripters will be happy. The configure
>>scripts will run at exactly the same s
In message <[EMAIL PROTECTED]>, Peter Seebach writ
es:
>Can we just kill this now? Take out the "-j", leave the support for getopts
>in the shell, and all the shell scripters will be happy. The configure
>scripts will run at exactly the same speed, and I will happily join in
>defending the decisi
Okay, some real data.
This is done using ash as of 20031007. The only change made is this:
*** builtins.def.orig Mon Dec 29 17:23:28 2003
--- builtins.defMon Dec 29 17:23:33 2003
***
*** 66,72
falsecmd false
histcmd -hfc
fgcmd -j fg
! getoptscmd -j
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>Perhaps. By your own admission, you used different source though so the
>results of the space savings are inconclusive, or more precisely,
>incompatible given the historical base.
I can't imagine that "the ash source" varies that widely.
>But
At 03:48 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>I see. So how does this thread differ from previous ones on this subject?
>
>Well, first off, I've done the obvious test, and verified that there is no
>"13k space saving". There might be 1/2k.
In message <[EMAIL PROTECTED]>, Brian Dessent writes:
>Peter Seebach wrote:
>> But, most importantly, it's in POSIX. I can see no reason for /bin/sh to not
>> be at least reasonably close to a POSIX shell, when the code is already
>> written.
>I was looking at the POSIX specs, and while getopts i
In message <[EMAIL PROTECTED]>, "Robb
, Sam" writes:
>> Well, first off, I've done the obvious test, and verified
>> that there is no "13k space saving". There might be 1/2k.
>There is no 13k space saving *now*. There may well have
>been with a previous set of sources and build tools.
I don't
Peter Seebach wrote:
> But, most importantly, it's in POSIX. I can see no reason for /bin/sh to not
> be at least reasonably close to a POSIX shell, when the code is already
> written.
I was looking at the POSIX specs, and while getopts is listed as a
required utility[1], and it is listed in the
> Well, first off, I've done the obvious test, and verified
> that there is no "13k space saving". There might be 1/2k.
There is no 13k space saving *now*. There may well have
been with a previous set of sources and build tools.
> I can indeed run tests, but right now, no one has offered
> e
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>I see. So how does this thread differ from previous ones on this subject?
Well, first off, I've done the obvious test, and verified that there is no
"13k space saving". There might be 1/2k.
>As far as I can see, you simply want to state your c
At 03:19 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>OK, sounds to me like you've convinced yourself that ash should contain
>>getopts. Does that mean that you no longer have a need to keep this thread
>>going? I'm not sure I see the discussion
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>OK, sounds to me like you've convinced yourself that ash should contain
>getopts. Does that mean that you no longer have a need to keep this thread
>going? I'm not sure I see the discussion providing any useful benefit beyond
>you becoming mor
At 02:54 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Igor Pechtcha
>nski writes:
>>I'm sure this discussion is in the archives somewhere.
>
>A first run of casual searching hasn't turned it up.
>
>However, since I happen to have an unmunged ash source around, I removed
In message <[EMAIL PROTECTED]>, Igor Pechtcha
nski writes:
>I'm sure this discussion is in the archives somewhere.
A first run of casual searching hasn't turned it up.
However, since I happen to have an unmunged ash source around, I removed
getopts from it.
# Without getopts
$ ls -l obj/sh
-rwxr
On Mon, 29 Dec 2003, Blair P. Houghton wrote:
> Peter Seebach wrote:
> >In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
> >>Use the "set -- `getopt`" idiom instead:
> >Yes, but *why*?
>
> ==
> % cygcheck --version
> cygcheck version 1.30
> System Checker for Cygwin
> Copyright 19
At 02:20 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, Larry Hall writes:
>>If you're curious, I suggest you run some timings on ash with and without
>>getopts enabled using a few configure scripts from some of Cygwin's
>>packages, large and small. It was the slowness
In message <[EMAIL PROTECTED]>, Larry Hall writes:
>If you're curious, I suggest you run some timings on ash with and without
>getopts enabled using a few configure scripts from some of Cygwin's
>packages, large and small. It was the slowness of configure scripts
>that prompted the streamlining
At 02:00 PM 12/29/2003, Peter Seebach you wrote:
>In message <[EMAIL PROTECTED]>, "Blair P. Houghto
>n" writes:
>>So I take it this "idiom" is only supposed to work in newer cygwin versions?
>
>I dunno. It's a very, very, odd idiom, that leaves you stuck with a great
>deal of manual parsing anyway
In message <[EMAIL PROTECTED]>, "Blair P. Houghto
n" writes:
>So I take it this "idiom" is only supposed to work in newer cygwin versions?
I dunno. It's a very, very, odd idiom, that leaves you stuck with a great
deal of manual parsing anyway.
>And I too am puzzled why someone would defeature a
Peter Seebach wrote:
>In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
>>Use the "set -- `getopt`" idiom instead:
>Yes, but *why*?
==
% cygcheck --version
cygcheck version 1.30
System Checker for Cygwin
Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
Compiled on Feb 8 2003
%
In message <[EMAIL PROTECTED]>, Dario Alcocer writes:
>Peter Seebach wrote:
>
>>I know this is a pseudo-FAQ, but I haven't been able to find a clear enough
>>answer in the archives.
>>
>>1. Is it not the case that POSIX provides a specification for the getopts
>>builtin?
>>2. Doesn't ash, as orig
Peter Seebach wrote:
I know this is a pseudo-FAQ, but I haven't been able to find a clear enough
answer in the archives.
1. Is it not the case that POSIX provides a specification for the getopts
builtin?
2. Doesn't ash, as originally written, implement getopts?
I'm trying to figure out why this
I know this is a pseudo-FAQ, but I haven't been able to find a clear enough
answer in the archives.
1. Is it not the case that POSIX provides a specification for the getopts
builtin?
2. Doesn't ash, as originally written, implement getopts?
I'm trying to figure out why this feature was removed,
35 matches
Mail list logo
