delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/11/21/05:24:19

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
X-Originating-IP: [12.75.26.159]
X-Originating-Email: [foobar1996 AT hotmail DOT com]
From: "David F" <foobar1996 AT hotmail DOT com>
To: cygwin AT cygwin DOT com
Subject: getopt() musings
Date: Fri, 21 Nov 2003 10:24:06 +0000
Mime-Version: 1.0
Message-ID: <BAY7-F56PeKljq65Rn8000006b7@hotmail.com>
X-OriginalArrivalTime: 21 Nov 2003 10:24:07.0000 (UTC) FILETIME=[9828FD80:01C3B019]

First off, let me state the facts as I understand them:

Cygwin's libc provides an implementation of getopt() and getopt_long().

The implementation provided in Cygwin is derived from the NetBSD 
implementation of getopt_long() witch was in turn designed to be reasonably 
compatible with GNU getopt_long().

Cygwin does not use the (traditional) getopt() implementation provided with 
newlib.

getopt() is a POSIX standard.

getopt_long() is a GNU extension.

Both the GNU and NetBSD implementations of getopt_long() also provide a 
version of getopt() with additional features that are not a part of (and 
incompatible with) POSIX getopt(). One additional feature of particular 
interest is argument permutation. The POSIX definition of getopt() specifies 
that all options must appear before any non-option arguments and so any 
option-like argument (one that starts with '-')  appearing after a 
non-option argument will not be treated as an option. With argument 
permutation, on the other hand, getopt() dynamically reorders the elements 
of the argv array so as to place all options before any non-options. This 
behavior is incompatible with the POSIX definition of getopt() and no doubt 
breaks some programs that rely on the traditional/standard behavior. For 
this reason the extend versions of getopt() provide ways to disable argument 
permutation. One way is by setting the environment variable POSIXLY_CORRECT, 
another is by passing a special character at the beginning of the (short) 
option string.

Cygwin's implementation of getopt() and getopt_long() were modified to leave 
argument permutation disabled by default and only enabled when the 
environment variable POSIXLY_INCORRECT_GETOPT is defined.

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

Additionally, I make the following suppositions:

Argument permutation is desierable. Except, of course, when it breaks 
something.

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.

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?

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

Cheers

_________________________________________________________________
From the hottest toys to tips on keeping fit this winter, you’ll find a 
range of helpful holiday info here.  
http://special.msn.com/network/happyholidays.armx


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019