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 if
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 what
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 this being the source of the word abysmal; I'm
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 it's hard
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 originally written
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 shell
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 of
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
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 more
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 case
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 think
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 is listed
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 I
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], 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 decision
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 job
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 results, I
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
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.
20 matches
Mail list logo
