[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33468: A bug with yes and --help
From: |
Eric Blake |
Subject: |
bug#33468: A bug with yes and --help |
Date: |
Tue, 12 Feb 2019 20:00:20 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 2/12/19 7:21 PM, Assaf Gordon wrote:
> Eric's suggestion was not wrong, "optint=0"
> was already used (and worked just fine) in parse_long_option.
>
> But there's a catch: after calling "parse_long_options"
> (which sets optind=0), every program called "getopt_long"
> again! and that call set optind to non-zero value.
>
> Bernhard's patch removed the (now unneeded) getopt_long call:
> ===
> - parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE, Version,
> - usage, AUTHORS, (char const *) NULL);
> - if (getopt_long (argc, argv, "", long_options, NULL) != -1)
> - usage (EXIT_FAILURE);
> + parse_gnu_standard_options_only (argc, argv, PROGRAM_NAME, PACKAGE,
> Version,
> + true, usage, AUTHORS, (char const *)
> NULL);
> ===
>
> And so all these programs were left with "optind=0" when the checked
> non-option arguments, e.g.:
>
> ===
> if (optind < argc)
> {
> error (0, 0, _("extra operand %s"), quote (argv[optind]));
> usage (EXIT_FAILURE);
> }
> ===
>
> which resulted in all the parsing errors I reported previously.
Aha. So the problem isn't resetting the parse, but the fact that
parse_long_options() left the parser in a different state than
parse_gnu_standard_options_only().
> parse_gnu_standard_options_only (argc, argv, PROGRAM_NAME,
PACKAGE_NAME, Version,
> true, usage, AUTHORS, (char const *)
> NULL);
> + optind = 1;
Why are you doing this in every caller, instead of doing it just once
inside the body of parse_gnu_standard_options_only(), so that the state
is left unchanged at optind==1 if there were no options parsed?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
- bug#33468: A bug with yes and --help, Assaf Gordon, 2019/02/12
- bug#33468: A bug with yes and --help,
Eric Blake <=
- bug#33468: A bug with yes and --help, Assaf Gordon, 2019/02/13
- bug#33468: A bug with yes and --help, Eric Blake, 2019/02/13
- bug#33468: A bug with yes and --help, Assaf Gordon, 2019/02/15
- bug#33468: A bug with yes and --help, Eric Blake, 2019/02/15
- bug#33468: A bug with yes and --help, Assaf Gordon, 2019/02/18
- bug#33468: A bug with yes and --help, Bernhard Voelker, 2019/02/19
- bug#33468: A bug with yes and --help, Assaf Gordon, 2019/02/19
- bug#33468: A bug with yes and --help, Eric Blake, 2019/02/19
- bug#33468: A bug with yes and --help, Bernhard Voelker, 2019/02/21
- bug#33468: A bug with yes and --help, Bernhard Voelker, 2019/02/22