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
Reply-To: Cygwin List <cygwin AT cygwin DOT com>
Message-Id: <6.0.1.1.0.20031229161810.03bbd940@127.0.0.1>
X-Sender: 
Date: Mon, 29 Dec 2003 17:10:24 -0500
To: seebs AT plethora DOT net (Peter Seebach), Cygwin List <cygwin AT cygwin DOT com>
From: Larry Hall <cygwin-lh AT cygwin DOT com>
Subject: Re: Question about ash and getopts
In-Reply-To: <200312292048.hBTKm6qd026306@guild.plethora.net>
References: <Your message of "Mon, 29 Dec 2003 15:34:06 EST." <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20031229152216 DOT 03bb6430 AT 127 DOT 0 DOT 0 DOT 1> <200312292048 DOT hBTKm6qd026306 AT guild DOT plethora DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:48 PM 12/29/2003, Peter Seebach you wrote:
>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.


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.  But I can't and won't argue you 
did not make an effort to investigate the "space saving" claim.  However, you 
need to be methodical and complete to make your efforts worthwhile.  If
you can compare ash using the current sources with and without the features
you want and prove there is no performance hit, then I'd say you have 
something very worthwhile.  If not, at least we have some good data to
point to, which it seems is part of your concern now.  This would be a 
productive effort, no matter what the outcome, which is why I suggested it.
But that doesn't mean you have to follow through obviously.
 

>>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.


I can't make any promises.  I'm not the ash maintainer and I won't speak
for her.  I can say that I've found this list to be very open to sound
results and good patches.  But the mantra is, PTC (patches thoughtfully
considered), which means any patch submitted is not automatically 
accepted.  In your case, the bar is raised rather high.  Performance of
configure scripts was abysmal when /bin/sh == /bin/bash.  That prompted 
the change to /bin/sh as ash.  A trimmed version of ash was introduced 
to save more time.  The difference was noticeable.  But, like I said,
this was a long time ago (/bin/sh as ash was introduced in B20 if I 
remember correctly).  So things may be different now.  And, they may not.
But the overwhelming consensus at the time was that this was all a change
for the better.  I don't think there will be much enthusiasm for a change
that slows down configures (thus another reason for the suggestion I made
about testing this with your getopts-enabled ash).  So, if you want to 
get this feature back into Cygwin's ash, you definitely will need to show
that it can be done without a performance penalty.

I think I've been pretty clear on this subject.  Unless you have a 
specific question that I haven't already answered, I don't plan to 
respond to further posts in this thread.  IMO, this has been discussed
more than sufficiently and further discussion is getting more and more 
off-topic.  For those interested in pushing for change in this area,
it's time to do.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/