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
