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 wo
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
In message <[EMAIL PROTECTED]>, =?iso-8859-2?B?RGFuaWVsIEplbGnxc2tp?=
writes:
>I am using gcc 3.3.1
>the same code works nicely on linux machine with gcc 3.3.1
>is any other information necessary?
What happens if you use %lld, which is what the standard specifies for long
long, instead of the L
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 t
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
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
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 happi
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
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
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
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
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
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
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
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
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
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,
Shouldn't the sh(1) man page mention the lack of getopts, rather than
documenting a feature which apparently got taken out?
For that matter, it seems to me that taking out a core POSIX feature is not
a very good way to make a shell smaller. getopts(1) was standardized because
it's VERY USEFUL. A
20 matches
Mail list logo
