This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: getopt() musings

It has again been some time since I've sent mail about the getopt issues ;-) I too would like to see getopt_long() allow parameter reordering, I'm fine with getopt() preserving posix correctness. Is anyone currently taking a look at this? What would be involved in the process?


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

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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]