bug-coreutils
[Top][All Lists]
Advanced

[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        

Attachment: 0001-all-parse_gnu_standard_options_only-fixup.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]