From: Neal D. Becker (ndbecker2_at_[hidden])
Date: 2004-05-07 06:32:44
Vladimir Prus wrote:
> Neal D. Becker wrote:
>> It's a small point, but here's my opinion. Â You say something like: "If
>> option requires a value and Â following -<number> doesn't match an option,
>> then parse it as an argument".
>> I would suggest "If option requires a value then parse *any* following
>> string, including -<number> as a value, unconditionally".
> So the different would be that
> -a -b
> where both "a" and "b" are allowed option and "-a" requires a value,
> will be reported as invalid value of option "-a" not as missing value on
> the command line? Why do you think that's better?
There are 2 choices:
1) Don't correctly parse some correct cases
2) Give confusing error message for incorrect case.
You'll agree #2 is better than #1.
where -3 is a valid option, and -a takes a value.
I suppose if you decide it's better to parse -3 as an option, then you do
have a workaround:
I'm not sure what gnu getopt does in this case (although it seems to always
do the right thing (TM), because I'm sure I've used this and never noticed
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk