bug#33468: A bug with yes and --help

[Bernhard Voelker]

On 11/24/18 1:52 AM, Pádraig Brady wrote:
> On 22/11/18 10:09, Uko Kokņevičs wrote:
>> So I was messing around with `yes`, and after running `yes --help me` it
>> output this:
>>
>>> yes: unrecognized option '--help'
>>> Try 'yes --help' for more information.
>>
>> After a bit of more testing of this, I found the same reaction from
>> `whoami`.  I believe this might be because both `yes` and `whoami` only
>> ever accept one option -- that being `--help` or `--version`, and it
>> says that it doesn't know what `--version` is when run with an extra
>> operand as well.  However, `true` or `false` doesn't give a textual
>> error, but they completely ignore the option:
>>
>>> $ /usr/bin/true --version
>>> true (GNU coreutils) 8.30
>>> Copyright (C) 2018 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>> <https://gnu.org/licenses/gpl.html>.
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by Jim Meyering.
>>> $ /usr/bin/true --version asd
>>> $ echo $?
>>> 0
>>
>> Suggested possible fixes:
>> 1.  A more general error message, e.g., `yes` only accepts one option or
>> none.
>> 2.  Ignore the stuff that follows the option, making `yes --help me` act
>> the same as `yes --help`, which kind of matches with other shell
>> commands in that they print help, ignore the rest of arguments and exit.
>> 3.  Ignore the option: `yes --help me` would use "--help me" as the
>> string to repeat.
>>
>> The third one isn't really a good one, but it exists as an idea so I'm
>> marking it down.
> 
> Yes this isn't ideal
> yes uses parse_long_options from gnulib which only processes
> options if there is a single option specified.
> 
> I see the message got a little more confusing since:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.28-42-g5782a36
> changing from unrecognized option '-', to unrecognized option '--help'
> Commands that use parse_long_options() are:
> 
>   cksum dd echo expr getlimits hostid hostname link logname nohup printf
>   sleep test tsort unlink uptime users whoami yes
> 
> thanks
> Pádraig

Ouch.  At least for 'yes', one could argument that the program should only
care about the (GNU) long options --help and --version if they are the
only argument, and take everything else as the string(s) to be output:

  $ src/yes --help | head -n2
  Usage: src/yes [STRING]...
    or:  src/yes OPTION

  $ src/yes --version | head -n2
  yes (GNU coreutils) 8.30.27-806b0
  Copyright (C) 2018 Free Software Foundation, Inc.

  $ src/yes --help me | head -n2
  src/yes --help me
  src/yes --help me

  $ src/yes | head -n 2
  src/yes
  src/yes

Patch below.
WDYT?

Have a nice day,
Berny

 diff --git a/src/yes.c b/src/yes.c
index 3dd5d2f9d..b86b439a4 100644
--- a/src/yes.c
+++ b/src/yes.c
@@ -32,11 +32,6 @@

 #define AUTHORS proper_name ("David MacKenzie")

-static struct option const long_options[] =
-{
-  {NULL, 0, NULL, 0}
-};
-
 void
 usage (int status)
 {
@@ -74,8 +69,6 @@ main (int argc, char **argv)

   parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, Version,
                       usage, AUTHORS, (char const *) NULL);
-  if (getopt_long (argc, argv, "+", long_options, NULL) != -1)
-    usage (EXIT_FAILURE);

   char **operands = argv + optind;
   char **operand_lim = argv + argc;