Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Question about ash and getopts
Date: Mon, 29 Dec 2003 16:19:19 -0500
Message-ID: <3D848382FB72E249812901444C6BDB1DE4DFAF@exchange.timesys.com>
From: "Robb, Sam" <sam DOT robb AT timesys DOT com>
To: "Cygwin List" <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

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

Immaterial, unless you think you somehow deserve an apology?

> The one evidential claim made in the past was that getopts
> was 13k of executable size.  It isn't.

As pointed out, all you know is that it isn't 13k *now*.
Besides, as Larry Hall has mentioned:

  "It was the slowness of configure scripts that prompted the
   streamlining of Cygwin's ash."

Larry's been around and involved in Cygwin for a good while, so
unless someone else can present some information that contradicts
his statement, I'm inclined to take his word on the matter.

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

You *do* know what the Cygwin motto is, don't you?

WJM. PTC.

The ball is in your court.  As Larry and others have mentioned,
you need to:

  (a) Show that ash without getopt no longer results in a
      significant space savings (which you've already done)
  (b) Show that ash + getopt no longer results in configure
      script slowness (yet to be done)
  (c) Contingent on (a) and (b), submit a patch to the ash
      maintainer that re-enables getopt in ash
 
> 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?

See (c), above.  I'd wager that without a patch from you,
the maintainer will have little or no reason to re-examine
the issue.

Providing a patch and data showing that there's no regression
to the slow-configure-script issue will probably significantly
increase the chance of the problem being addressed.

> I see no reason to believe it, simply because there's never been
> any evidence that getopts was causing problems in the first place.

Maybe I'm naieve; but my thought is that at some point, people
who knew what they were doing made the decision that removing
getopt support from ash as a Good Thing.

While I have come to know and respect the people who apparently
made this decision, I have no idea who you are.

You've gained some measure of credibility by bringing up the issue,
and doing some simple experimentation to prove your point.  It's a
shame that there is an increasingly shrill tone in your messages that
is swamping out your more reasoned arguments.

-Samrobb

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