This is the mail archive of the
mailing list for the Cygwin project.
- From: "David F" <foobar1996 at hotmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 21 Nov 2003 10:24:06 +0000
- Subject: getopt() musings
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
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)
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
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
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.
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
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.)
From the hottest toys to tips on keeping fit this winter, you?ll find a
range of helpful holiday info here.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html