Am 02.10.21 um 10:35 schrieb Ævar Arnfjörð Bjarmason:
>
> On Fri, Oct 01 2021, Junio C Hamano wrote:
>
>> René Scharfe <l.s.r@xxxxxx> writes:
>>
>>> int cmd__mergesort(int argc, const char **argv)
>>> {
>>> if (argc == 2 && !strcmp(argv[1], "sort"))
>>> return sort_stdin();
>>> - usage("test-tool mergesort sort");
>>> + if (argc > 1 && !strcmp(argv[1], "test"))
>>> + return run_tests(argc - 2, argv + 2);
>>> + fprintf(stderr, "usage: test-tool mergesort sort\n");
>>> + fprintf(stderr, " or: test-tool mergesort test [<n>...]\n");
>>> + return 129;
>>
>> If you can live with OPT_CMDMODE to implement sort/test subcommands,
>> you'd get to have parse_options() to do the usage for you, I think.
>> I am not sure if it is worth it, as t/helper/ is not end-user
>> facing.
>
> Yeah I think the one thing that could improve here is this custom
> getopts handling, in particular the manual formatting of "usage" and
> "or" is a bit ugly, considering that you'll get it for free with the
> parse_options() "usage" array.
I don't see how using parseopt would help here. Maintaining the "usage"
and "or" strings manually is trivial. The meaty part of the usage
string (e.g. "test [<n>...]") would not be generated, neither would the
repeated part ("test-tool mergesort"). OPT_CMDMODE would require
double dashes for no good reason.
PowerShell's param array allows specifying value types, positions and
group parameters into sets. I think it's expressive enough to allow
declaring all three subcommands and their parameters, and then can
parse command lines and generate help text automatically.
Until parseopt gains similar capabilities I'd like to avoid that
dependency.
René
