On Mon, Jun 23, 2008 at 05:15:41AM +0000, Linus Torvalds wrote:
> I think I'll want to add a PARSE_OPT_IGNORE_UNRECOGNIZED flag, and also
> make it not write the resulting array into argv[0..] but back into
> argv[1..] (so that you can use parse_options() as a _filter_ for options
> parsing and make it easier to do partial conversions), but in the meantime
> this mostly works.
You can't, mainly because of option aggregation: if the parser1 knows
about -a and -b, parser2 about -c, then, this kind of things is
problematic: -acb because you need to go to the parser '2' to know about
-c, and you can't filter the arguments and keep -c and give -b to
parser1 again, *BECAUSE* 'b' could also be -c argument.
This "PARSE_OPT_IGNORE_UNRECOGNIZED" thing has been discussed many times
in the past, but it just doesn't fly.
Though to help migrations we can probably introduce a new parse option
construct that would be a callback that is responsible for dealing with
"things" the upper level parser doesn't know about, something where the
callback could be:
enum {
FLAG_ERROR = -1,
FLAG_NOT_FOR_ME,
FLAG_IS_FOR_ME,
FLAG_AND_VALUE_ARE_FOR_ME,
}
int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
const char *value, void *priv);
Where the callback is supposed to work that way:
we pass to it either a shortopt ('\0' else) or a longopt (NULL else) but
never both, and what the parser could find as a possible value in value
(NULL if no value found). Then the parser does what it has to, and
returns one of the previous enum values. ERROR would be a fatal error
(-1 chosen so that one can return error(...)), NOT_FOR_ME if it didn't
want the flag after all, IS_FOR_ME if it took only the flag, without the
value, the last one being if it consumed both the option flag _and_ the
value.
Of course for things like --long-opt=value if the callback doesn't eat
the value, then parse_options would have to barf loudly.
The major drawback of this method is that parse_options won't generate
the nice usage help for the things that recurse in such a function. But
at least it eases migration to parseoptions, because I believe rev_parse
and diff_opt_parse to be _way_ easier to migrate to such a callback
_and_ with the old API together (I really believe that the old big
consuming loops could use such a callback directly e.g.) so that
commands using diff and revision options can be migrated to parse-opt
*slowly* rather than all at a time (which is a no-go and is such a big
amount of work that I avoided it in despair).
If people believe it's a sane approach I can do it. I absolutely don't
know why no one thought of that before, but I don't see any major
drawback (except for the "help" bits, but like I said, it's a "code
upgrade path" and not meant to be the final state).
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpGVsqlKpH97.pgp
Description: PGP signature
