2018-09-09 17:36:29 +00:00
|
|
|
#include "test-tool.h"
|
2007-10-13 16:34:45 +00:00
|
|
|
#include "parse-options.h"
|
2023-04-22 20:17:08 +00:00
|
|
|
#include "strbuf.h"
|
2011-06-09 15:55:23 +00:00
|
|
|
#include "string-list.h"
|
2019-02-22 22:25:01 +00:00
|
|
|
#include "trace2.h"
|
2007-10-13 16:34:45 +00:00
|
|
|
|
|
|
|
static int boolean = 0;
|
2008-07-30 19:53:45 +00:00
|
|
|
static int integer = 0;
|
2015-06-21 18:25:44 +00:00
|
|
|
static unsigned long magnitude = 0;
|
2017-04-26 19:29:31 +00:00
|
|
|
static timestamp_t timestamp;
|
2008-06-22 15:04:26 +00:00
|
|
|
static int abbrev = 7;
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
static int verbose = -1; /* unspecified */
|
|
|
|
static int dry_run = 0, quiet = 0;
|
2007-10-13 16:34:45 +00:00
|
|
|
static char *string = NULL;
|
2009-05-23 18:53:13 +00:00
|
|
|
static char *file = NULL;
|
2009-09-25 18:44:44 +00:00
|
|
|
static int ambiguous;
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2016-05-05 20:30:10 +00:00
|
|
|
static struct {
|
|
|
|
int called;
|
|
|
|
const char *arg;
|
|
|
|
int unset;
|
|
|
|
} length_cb;
|
|
|
|
|
2009-06-18 17:28:43 +00:00
|
|
|
static int length_callback(const struct option *opt, const char *arg, int unset)
|
2008-06-22 15:04:26 +00:00
|
|
|
{
|
2016-05-05 20:30:10 +00:00
|
|
|
length_cb.called = 1;
|
|
|
|
length_cb.arg = arg;
|
|
|
|
length_cb.unset = unset;
|
|
|
|
|
2008-06-22 15:04:26 +00:00
|
|
|
if (unset)
|
|
|
|
return 1; /* do not support unset */
|
|
|
|
|
2008-08-14 00:48:57 +00:00
|
|
|
*(int *)opt->value = strlen(arg);
|
2008-06-22 15:04:26 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-18 17:28:43 +00:00
|
|
|
static int number_callback(const struct option *opt, const char *arg, int unset)
|
2009-05-07 19:45:08 +00:00
|
|
|
{
|
assert NOARG/NONEG behavior of parse-options callbacks
When we define a parse-options callback, the flags we put in the option
struct must match what the callback expects. For example, a callback
which does not handle the "unset" parameter should only be used with
PARSE_OPT_NONEG. But since the callback and the option struct are not
defined next to each other, it's easy to get this wrong (as earlier
patches in this series show).
Fortunately, the compiler can help us here: compiling with
-Wunused-parameters can show us which callbacks ignore their "unset"
parameters (and likewise, ones that ignore "arg" expect to be triggered
with PARSE_OPT_NOARG).
But after we've inspected a callback and determined that all of its
callers use the right flags, what do we do next? We'd like to silence
the compiler warning, but do so in a way that will catch any wrong calls
in the future.
We can do that by actually checking those variables and asserting that
they match our expectations. Because this is such a common pattern,
we'll introduce some helper macros. The resulting messages aren't
as descriptive as we could make them, but the file/line information from
BUG() is enough to identify the problem (and anyway, the point is that
these should never be seen).
Each of the annotated callbacks in this patch triggers
-Wunused-parameters, and was manually inspected to make sure all callers
use the correct options (so none of these BUGs should be triggerable).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 06:45:42 +00:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
2009-05-07 19:45:08 +00:00
|
|
|
*(int *)opt->value = strtol(arg, NULL, 10);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-05 21:36:55 +00:00
|
|
|
static int collect_expect(const struct option *opt, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct string_list *expect;
|
|
|
|
struct string_list_item *item;
|
|
|
|
struct strbuf label = STRBUF_INIT;
|
|
|
|
const char *colon;
|
|
|
|
|
|
|
|
if (!arg || unset)
|
|
|
|
die("malformed --expect option");
|
|
|
|
|
|
|
|
expect = (struct string_list *)opt->value;
|
|
|
|
colon = strchr(arg, ':');
|
|
|
|
if (!colon)
|
|
|
|
die("malformed --expect option, lacking a colon");
|
|
|
|
strbuf_add(&label, arg, colon - arg);
|
|
|
|
item = string_list_insert(expect, strbuf_detach(&label, NULL));
|
|
|
|
if (item->util)
|
|
|
|
die("malformed --expect option, duplicate %s", label.buf);
|
|
|
|
item->util = (void *)arg;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
__attribute__((format (printf,3,4)))
|
|
|
|
static void show(struct string_list *expect, int *status, const char *fmt, ...)
|
|
|
|
{
|
|
|
|
struct string_list_item *item;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
|
|
|
strbuf_vaddf(&buf, fmt, args);
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
if (!expect->nr)
|
|
|
|
printf("%s\n", buf.buf);
|
|
|
|
else {
|
|
|
|
char *colon = strchr(buf.buf, ':');
|
|
|
|
if (!colon)
|
|
|
|
die("malformed output format, output lacking colon: %s", fmt);
|
|
|
|
*colon = '\0';
|
|
|
|
item = string_list_lookup(expect, buf.buf);
|
|
|
|
*colon = ':';
|
|
|
|
if (!item)
|
|
|
|
; /* not among entries being checked */
|
|
|
|
else {
|
|
|
|
if (strcmp((const char *)item->util, buf.buf)) {
|
|
|
|
printf("-%s\n", (char *)item->util);
|
|
|
|
printf("+%s\n", buf.buf);
|
|
|
|
*status = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
2018-09-09 17:36:29 +00:00
|
|
|
int cmd__parse_options(int argc, const char **argv)
|
2007-10-13 16:34:45 +00:00
|
|
|
{
|
2009-05-23 18:53:13 +00:00
|
|
|
const char *prefix = "prefix/";
|
2007-10-13 16:34:45 +00:00
|
|
|
const char *usage[] = {
|
2018-09-09 17:36:29 +00:00
|
|
|
"test-tool parse-options <options>",
|
2017-09-25 04:08:03 +00:00
|
|
|
"",
|
|
|
|
"A helper function for the parse-options API.",
|
2007-10-13 16:34:45 +00:00
|
|
|
NULL
|
|
|
|
};
|
2016-05-05 21:36:55 +00:00
|
|
|
struct string_list expect = STRING_LIST_INIT_NODUP;
|
2021-10-07 10:01:32 +00:00
|
|
|
struct string_list list = STRING_LIST_INIT_NODUP;
|
|
|
|
|
2007-10-13 16:34:45 +00:00
|
|
|
struct option options[] = {
|
2012-02-25 19:11:16 +00:00
|
|
|
OPT_BOOL(0, "yes", &boolean, "get a boolean"),
|
|
|
|
OPT_BOOL('D', "no-doubt", &boolean, "begins with 'no-'"),
|
|
|
|
{ OPTION_SET_INT, 'B', "no-fear", &boolean, NULL,
|
|
|
|
"be brave", PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, 1 },
|
|
|
|
OPT_COUNTUP('b', "boolean", &boolean, "increment by one"),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_BIT('4', "or4", &boolean,
|
|
|
|
"bitwise-or boolean with ...0100", 4),
|
2009-05-07 19:44:17 +00:00
|
|
|
OPT_NEGBIT(0, "neg-or4", &boolean, "same as --no-or4", 4),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_GROUP(""),
|
2007-10-13 16:34:45 +00:00
|
|
|
OPT_INTEGER('i', "integer", &integer, "get a integer"),
|
|
|
|
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
|
2015-06-21 18:25:44 +00:00
|
|
|
OPT_MAGNITUDE('m', "magnitude", &magnitude, "get a magnitude"),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
|
2020-02-20 14:15:15 +00:00
|
|
|
OPT_CMDMODE(0, "mode1", &integer, "set integer to 1 (cmdmode option)", 1),
|
|
|
|
OPT_CMDMODE(0, "mode2", &integer, "set integer to 2 (cmdmode option)", 2),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_CALLBACK('L', "length", &integer, "str",
|
|
|
|
"get length of <str>", length_callback),
|
2011-02-15 13:09:13 +00:00
|
|
|
OPT_FILENAME('F', "file", &file, "set file to <file>"),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_GROUP("String options"),
|
2007-10-13 16:34:45 +00:00
|
|
|
OPT_STRING('s', "string", &string, "string", "get a string"),
|
|
|
|
OPT_STRING(0, "string2", &string, "str", "get another string"),
|
2007-11-05 13:15:21 +00:00
|
|
|
OPT_STRING(0, "st", &string, "st", "get another string (pervert ordering)"),
|
2008-01-26 11:26:57 +00:00
|
|
|
OPT_STRING('o', NULL, &string, "str", "get another string"),
|
2011-09-28 17:44:30 +00:00
|
|
|
OPT_NOOP_NOARG(0, "obsolete"),
|
2023-07-18 22:54:04 +00:00
|
|
|
OPT_SET_INT_F(0, "longhelp", &integer, "help text of this entry\n"
|
|
|
|
"spans multiple lines", 0, PARSE_OPT_NONEG),
|
2011-06-09 15:55:23 +00:00
|
|
|
OPT_STRING_LIST(0, "list", &list, "str", "add str to list"),
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_GROUP("Magic arguments"),
|
2009-05-07 19:45:08 +00:00
|
|
|
OPT_NUMBER_CALLBACK(&integer, "set integer to NUM",
|
|
|
|
number_callback),
|
2012-02-25 19:11:16 +00:00
|
|
|
{ OPTION_COUNTUP, '+', NULL, &boolean, NULL, "same as -b",
|
2009-05-07 19:45:42 +00:00
|
|
|
PARSE_OPT_NOARG | PARSE_OPT_NONEG | PARSE_OPT_NODASH },
|
2012-02-25 19:11:16 +00:00
|
|
|
{ OPTION_COUNTUP, 0, "ambiguous", &ambiguous, NULL,
|
2009-09-25 18:44:44 +00:00
|
|
|
"positive ambiguity", PARSE_OPT_NOARG | PARSE_OPT_NONEG },
|
2012-02-25 19:11:16 +00:00
|
|
|
{ OPTION_COUNTUP, 0, "no-ambiguous", &ambiguous, NULL,
|
2009-09-25 18:44:44 +00:00
|
|
|
"negative ambiguity", PARSE_OPT_NOARG | PARSE_OPT_NONEG },
|
2008-06-22 15:04:26 +00:00
|
|
|
OPT_GROUP("Standard options"),
|
|
|
|
OPT__ABBREV(&abbrev),
|
2010-11-08 17:56:39 +00:00
|
|
|
OPT__VERBOSE(&verbose, "be verbose"),
|
2010-11-08 17:58:51 +00:00
|
|
|
OPT__DRY_RUN(&dry_run, "dry run"),
|
2010-11-08 18:06:54 +00:00
|
|
|
OPT__QUIET(&quiet, "be quiet"),
|
2016-05-05 21:36:55 +00:00
|
|
|
OPT_CALLBACK(0, "expect", &expect, "string",
|
|
|
|
"expected output in the variable dump",
|
|
|
|
collect_expect),
|
2019-04-29 10:05:25 +00:00
|
|
|
OPT_GROUP("Alias"),
|
|
|
|
OPT_STRING('A', "alias-source", &string, "string", "get a string"),
|
|
|
|
OPT_ALIAS('Z', "alias-target", "alias-source"),
|
2007-10-13 16:34:45 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
int i;
|
2016-05-05 21:36:55 +00:00
|
|
|
int ret = 0;
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2019-02-22 22:25:01 +00:00
|
|
|
trace2_cmd_name("_parse_");
|
|
|
|
|
2013-04-27 19:19:47 +00:00
|
|
|
argc = parse_options(argc, (const char **)argv, prefix, options, usage, 0);
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2016-05-05 20:30:10 +00:00
|
|
|
if (length_cb.called) {
|
|
|
|
const char *arg = length_cb.arg;
|
|
|
|
int unset = length_cb.unset;
|
2016-05-05 21:36:55 +00:00
|
|
|
show(&expect, &ret, "Callback: \"%s\", %d",
|
|
|
|
(arg ? arg : "not set"), unset);
|
2016-05-05 20:30:10 +00:00
|
|
|
}
|
2016-05-05 21:36:55 +00:00
|
|
|
show(&expect, &ret, "boolean: %d", boolean);
|
|
|
|
show(&expect, &ret, "integer: %d", integer);
|
|
|
|
show(&expect, &ret, "magnitude: %lu", magnitude);
|
2017-04-21 10:45:48 +00:00
|
|
|
show(&expect, &ret, "timestamp: %"PRItime, timestamp);
|
2016-05-05 21:36:55 +00:00
|
|
|
show(&expect, &ret, "string: %s", string ? string : "(not set)");
|
|
|
|
show(&expect, &ret, "abbrev: %d", abbrev);
|
|
|
|
show(&expect, &ret, "verbose: %d", verbose);
|
|
|
|
show(&expect, &ret, "quiet: %d", quiet);
|
|
|
|
show(&expect, &ret, "dry run: %s", dry_run ? "yes" : "no");
|
|
|
|
show(&expect, &ret, "file: %s", file ? file : "(not set)");
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2011-06-09 15:55:23 +00:00
|
|
|
for (i = 0; i < list.nr; i++)
|
2016-05-05 21:36:55 +00:00
|
|
|
show(&expect, &ret, "list: %s", list.items[i].string);
|
2011-06-09 15:55:23 +00:00
|
|
|
|
2007-10-13 16:34:45 +00:00
|
|
|
for (i = 0; i < argc; i++)
|
2016-05-05 21:36:55 +00:00
|
|
|
show(&expect, &ret, "arg %02d: %s", i, argv[i]);
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2021-10-07 10:01:32 +00:00
|
|
|
expect.strdup_strings = 1;
|
|
|
|
string_list_clear(&expect, 0);
|
|
|
|
string_list_clear(&list, 0);
|
|
|
|
|
2016-05-05 21:36:55 +00:00
|
|
|
return ret;
|
2007-10-13 16:34:45 +00:00
|
|
|
}
|
2022-08-19 16:03:55 +00:00
|
|
|
|
|
|
|
static void print_args(int argc, const char **argv)
|
|
|
|
{
|
2022-09-05 18:50:04 +00:00
|
|
|
int i;
|
|
|
|
for (i = 0; i < argc; i++)
|
2022-08-19 16:03:55 +00:00
|
|
|
printf("arg %02d: %s\n", i, argv[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_options_flags__cmd(int argc, const char **argv,
|
|
|
|
enum parse_opt_flags test_flags)
|
|
|
|
{
|
|
|
|
const char *usage[] = {
|
|
|
|
"<...> cmd [options]",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
int opt = 0;
|
|
|
|
const struct option options[] = {
|
|
|
|
OPT_INTEGER('o', "opt", &opt, "an integer option"),
|
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options, usage, test_flags);
|
|
|
|
|
|
|
|
printf("opt: %d\n", opt);
|
|
|
|
print_args(argc, argv);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum parse_opt_flags test_flags = 0;
|
|
|
|
static const struct option test_flag_options[] = {
|
|
|
|
OPT_GROUP("flag-options:"),
|
|
|
|
OPT_BIT(0, "keep-dashdash", &test_flags,
|
|
|
|
"pass PARSE_OPT_KEEP_DASHDASH to parse_options()",
|
|
|
|
PARSE_OPT_KEEP_DASHDASH),
|
|
|
|
OPT_BIT(0, "stop-at-non-option", &test_flags,
|
|
|
|
"pass PARSE_OPT_STOP_AT_NON_OPTION to parse_options()",
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION),
|
|
|
|
OPT_BIT(0, "keep-argv0", &test_flags,
|
|
|
|
"pass PARSE_OPT_KEEP_ARGV0 to parse_options()",
|
|
|
|
PARSE_OPT_KEEP_ARGV0),
|
2022-08-19 16:03:57 +00:00
|
|
|
OPT_BIT(0, "keep-unknown-opt", &test_flags,
|
|
|
|
"pass PARSE_OPT_KEEP_UNKNOWN_OPT to parse_options()",
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN_OPT),
|
2022-08-19 16:03:55 +00:00
|
|
|
OPT_BIT(0, "no-internal-help", &test_flags,
|
|
|
|
"pass PARSE_OPT_NO_INTERNAL_HELP to parse_options()",
|
|
|
|
PARSE_OPT_NO_INTERNAL_HELP),
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
OPT_BIT(0, "subcommand-optional", &test_flags,
|
|
|
|
"pass PARSE_OPT_SUBCOMMAND_OPTIONAL to parse_options()",
|
|
|
|
PARSE_OPT_SUBCOMMAND_OPTIONAL),
|
2022-08-19 16:03:55 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
|
|
|
int cmd__parse_options_flags(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
const char *usage[] = {
|
|
|
|
"test-tool parse-options-flags [flag-options] cmd [options]",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, test_flag_options, usage,
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
|
2022-09-05 18:50:05 +00:00
|
|
|
if (!argc || strcmp(argv[0], "cmd")) {
|
2022-08-19 16:03:55 +00:00
|
|
|
error("'cmd' is mandatory");
|
|
|
|
usage_with_options(usage, test_flag_options);
|
|
|
|
}
|
|
|
|
|
|
|
|
return parse_options_flags__cmd(argc, argv, test_flags);
|
|
|
|
}
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
|
2023-03-28 20:57:25 +00:00
|
|
|
static int subcmd_one(int argc, const char **argv, const char *prefix UNUSED)
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
{
|
|
|
|
printf("fn: subcmd_one\n");
|
|
|
|
print_args(argc, argv);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-03-28 20:57:25 +00:00
|
|
|
static int subcmd_two(int argc, const char **argv, const char *prefix UNUSED)
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
{
|
|
|
|
printf("fn: subcmd_two\n");
|
|
|
|
print_args(argc, argv);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_subcommand__cmd(int argc, const char **argv,
|
|
|
|
enum parse_opt_flags test_flags)
|
|
|
|
{
|
|
|
|
const char *usage[] = {
|
|
|
|
"<...> cmd subcmd-one",
|
|
|
|
"<...> cmd subcmd-two",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
parse_opt_subcommand_fn *fn = NULL;
|
|
|
|
int opt = 0;
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_SUBCOMMAND("subcmd-one", &fn, subcmd_one),
|
|
|
|
OPT_SUBCOMMAND("subcmd-two", &fn, subcmd_two),
|
|
|
|
OPT_INTEGER('o', "opt", &opt, "an integer option"),
|
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
|
|
|
if (test_flags & PARSE_OPT_SUBCOMMAND_OPTIONAL)
|
|
|
|
fn = subcmd_one;
|
|
|
|
argc = parse_options(argc, argv, NULL, options, usage, test_flags);
|
|
|
|
|
|
|
|
printf("opt: %d\n", opt);
|
|
|
|
|
|
|
|
return fn(argc, argv, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
int cmd__parse_subcommand(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
const char *usage[] = {
|
|
|
|
"test-tool parse-subcommand [flag-options] cmd <subcommand>",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, test_flag_options, usage,
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
|
2022-09-05 18:50:05 +00:00
|
|
|
if (!argc || strcmp(argv[0], "cmd")) {
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
error("'cmd' is mandatory");
|
|
|
|
usage_with_options(usage, test_flag_options);
|
|
|
|
}
|
|
|
|
|
|
|
|
return parse_subcommand__cmd(argc, argv, test_flags);
|
|
|
|
}
|