This is the mail archive of the
mailing list for the Cygwin project.
Re: Question about ash and getopts
- From: seebs at plethora dot net (Peter Seebach)
- To: Cygwin List <cygwin at cygwin dot com>
- Date: Mon, 29 Dec 2003 14:48:06 -0600
- Subject: Re: Question about ash and getopts
- Reply-to: seebs at plethora dot net (Peter Seebach)
In message <email@example.com>, 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 but not contribute
>anything in return. We've had threads like that. If you *really* want
>to see a change here, you have to put some effort into it. That means
>looking at the issue objectively, running some tests, and if those tests
>bear out, sharing them with the list along with the patch to enable the
>features you want and that your tests validate.
I can indeed run tests, but right now, no one has offered even a TINY SHRED
of actual evidence that the current broken behavior ever saved any space or
The one evidential claim made in the past was that getopts was 13k of
executable size. It isn't.
The resistence here makes no sense. The code is already written; it is in
ash, as it has been forever. There is no evidence showing that removing half
a kilobyte of executable code makes any measurable difference at all.
This suggests to me that no amount of testing matters; the decision here is
an ego one, not an engineering one. The decision Was Made; therefore it is
the Cygwin Way to break /bin/sh in the name of saving space, even if the space
savings are actually 1/26th of what was claimed.
Can anyone honestly tell me that, if it turns out that enabling getopts
imposes no significant performance penalty, that this will result in fixing
the shell? I see no reason to believe it, simply because there's never been
any evidence that getopts was causing problems in the first place.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html