Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <200312292048.hBTKm6qd026306@guild.plethora.net>
From: seebs AT plethora DOT net (Peter Seebach)
Reply-To: seebs AT plethora DOT net (Peter Seebach)
To: Cygwin List <cygwin AT cygwin DOT com>
Subject: Re: Question about ash and getopts
In-reply-to: Your message of "Mon, 29 Dec 2003 15:34:06 EST." <6.0.1.1.0.20031229152216.03bb6430@127.0.0.1>
Date: Mon, 29 Dec 2003 14:48:06 -0600
X-IsSubscribed: yes

In message <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20031229152216 DOT 03bb6430 AT 127 DOT 0 DOT 0 DOT 1>, 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
time.

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.

-s

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/