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: <007c01c3b1c6$91db3890$78d96f83@starfruit>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "David F" <foobar1996 AT hotmail DOT com>, <cygwin AT cygwin DOT com>
References: <BAY7-F56PeKljq65Rn8000006b7 AT hotmail DOT com>
Subject: Re: getopt() musings
Date: Sun, 23 Nov 2003 13:33:33 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Note-from-DJ: This may be spam

David F wrote:
> First off, let me state the facts as I understand them:
...
> Ok, those are the facts as I understand them, if I am wrong about
> anything I trust that I will be corrected with expeditious and
> forthright meanness. :)

I haven't verified your facts, but they sound plausible.

> Additionally, I make the following suppositions:
>
> Argument permutation is desierable. Except, of course, when it breaks
> something.

I agree.

> It would be overly burdensome to explicitly enable/disable getopt()
> features on a case-by-case basis for getopt() using packages that are
> part of the Cygwin distribution.

Definitely, that wouldn't happen.

> And now for some discussion:
>
> I am not familiar with all the details of the evolution of
> getopt_long(), but I assume that argument permutation was present and
> enabled by default fairly early. I therefore assume that programs
> using getopt_long() are either compatible with argument permutatuin
> or have explicitly disabled it.
>
> So here's the idea: Leave argument permutation disabled by default for
> getopt() and enabled by default for getopt_long().
>
> This is a win if only because many if not most GNU programs use
> getopt_long(), especially those in the coreutils package.
>
> This would allow us the convenience of argument permutation for many
> programs while also maintaining standards compliance and
> compatibility. Right?

I don't know. If correct, that would be excellent.

> So it could work like this:
>
> getopt() would have argument permutation disabled by default and only
> enabled when POSIXLY_INCORRECT_GETOPT is defined and it is not
> explicitly disabled by the calling code.
>
> getopt_long() would have argument permutation enabled by default and
> disabled when POSIXLY_CORRECT is defined or it is explicitly disabled
> by the calling code.
>
> Does any of this make sense?
>
> (Note that I'm not asking anyone to implement this and I am familiar
> with the concept of "PTC". For now, I would just like to know what
> others think.)

I think it makes a lot of sense. It does require someone to put in a fair
amount of time:

1) Resolving the uncertainties you mention.
2) Finding out what permutation broke in the first place.
3) Making the necessary tweaks
4) Verifying nothing is broken.

I think its a worthwhile cause, but I don't have the time to dedicate to it
just right now.


Max.


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