[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33468: A bug with yes and --help
From: |
Assaf Gordon |
Subject: |
bug#33468: A bug with yes and --help |
Date: |
Tue, 12 Feb 2019 18:21:36 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
Hello,
A follow-up and more details:
On 2019-01-12 11:30 a.m., Assaf Gordon wrote:
On 2019-01-12 8:42 a.m., Eric Blake wrote:
On 1/11/19 6:23 PM, Assaf Gordon wrote:
- optind = 0;
+ optind = 1;
Ouch. You're hitting the portability problem of the difference between
BSD and glibc.
I only tested on Debian Stretch (with Debian GLIBC 2.24-11+deb9u3),
did not yet test on BSDs.
With "optind=1", I see the following:
===
$ ./src/hostid
ec68f06c
[...]
With "optind=0" I see the following:
===
$ ./src/hostid
./src/hostid: extra operand ‘./src/hostid’
Try './src/hostid --help' for more information.
====
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.
Perhaps "parse_gnu_standard_options_only" should use "_getopt_long_r"
and avoid the need to reset anything?
_getopt_long_r was ostensibly fine, but turned out to be messy:
when coreutils is built on glibc systems, all of gnulib's getopt
replacement modules are not used, and so _getopt_long_r is not
available.
As all the programs in this patch accept only --help and --yes
(and non-option arguments), the attached ugly hack seems to solve the
issue.
There's probably a prettier way.
With this patch, the only issues left are nohup's exit code (1 instead
of 125) and "dd --", see https://bugs.gnu.org/33468#29
regards,
- assaf
0001-all-parse_gnu_standard_options_only-fixup.patch
Description: Text Data
- bug#33468: A bug with yes and --help,
Assaf Gordon <=
- bug#33468: A bug with yes and --help, Eric Blake, 2019/02/12
- 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