On Wed, 24 Nov 2004 17:14:03 +0300 Vladimir Prus <ghost@cs.msu.su> wrote:
Caleb Epstein wrote:
On Wed, 24 Nov 2004 10:27:59 +0300, Vladimir Prus <ghost@cs.msu.su> wrote:
Ok, let me start with a caveat: ignoring unknown options can be ambiguous:
program --something 10 --known_option
Now, is "10" a value of unknown option or positional option? To remove> the problems all unknown options must use this form:
--something=10
which may be problem, or may not, depending on your situation. What do> you think?
I think it is unreasonable to expect all command lines to be specified in this way. If --something expects an argument, then 10 is that argument.
Well, I obvious don't know if an unknown option expects an argument ;-)
Right, but the custom parser better. It should hold state and know what is supposed to come next. However, it can only do this if the custom parser is allowed to eat up the option, leaving the "driver" with nothing to do at all for that option (like a Jedi mind trick, "This is not the option you are looking for.") Imagine a custom parser written like this... enum action_t { a_none, a_modified, a_comsumed }; action_t action = a_none; switch (state_) { case s_idle: if (option == "--something") { state_ = s_something; action = a_consumed; } break; case s_something: { action = a_consumed; char * p; long val = strtol(option.c_str(), &p, 0); if (/*something is valid*/) { state_ = s_idle; } else { // I expected a value for "something" // What do I do here? There is no way to return an error // to the driver caller. Should I throw an exception? } } break; ... } switch (action) { case a_none: // return something saying that I did nothing with this option break; case a_modified: // return a name/value tuple, similar to the current interface break; case a_consumed: // return something saying that this option has been // consumed, and the driver should pretend like it // never even existed. break; }
If --something is a flag then its either an unknown argument or (if you allow argument vector rearranging ala GNU getopt) it is the first positional parameter.
While it's possible to consider all unknown options to be positional options, this still leaves the question what to do with "10". Should it be passed to the application as position option?
If you want to allow positional options to be mixed with non-positional options, then yes, it would be treated as a positional option.
Allowing unknown options to be ignored is a very desirable feature, though it should be disabled by default.
I just don't see any solution to make unknown options work without either-- requiring --something=10 format -- requiring that all positional options are at the end
If the custom parser can actually "consume" options, then the "10" would not be left over at all... I am afraid we have a misunderstanding somewhere...