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: Eric Blake
Subject: bug#33468: A bug with yes and --help
Date: Fri, 15 Feb 2019 14:19:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/15/19 12:32 PM, Assaf Gordon wrote:

> Attached updated patches, with tests.

It's easier to review patches when they are attached inline without
compression (then I don't have to decompress and copy from my editor
back into my email), but I can cope with your .gz attachments.

> 
> comments welcomed,
>  - assaf
> 
>  P.S.
> There is at least one change in behavior, not sure if this is
> bad enough to be a regression or doesn't really matter:
> 
>   $ yes-OLD me -- --help | head -n1
>   me -- --help
> 
>   $ yes-NEW me -- --help | head -n1
>   me --help

I would argue bug-fix. My reference is any other getopt-based utility
where -- has observable effects when treated as an explicit option:

$ echo pattern > ./--
$ grep pattern -- </dev/null
$ POSIXLY_CORRECT=1 grep pattern -- </dev/null
pattern
$ grep -- pattern -- </dev/null
pattern

That is, the value of POSIXLY_CORRECT determines whether to permute the
'end-of-option' behavior of '--' prior to non-options (GNU behavior) or
to strictly treat the first non-option as end-of-options (POSIX
behavior), and the user can always add an explicit -- prior to
non-options to guarantee POSIX behavior regardless of POSIXLY_CORRECT.

So, I would suspect (although I have not yet tesed) that as patched, you
would get:

$ yes-NEW me -- --help | head -n1
me --help
$ POSIXLY_CORRECT=1 yes-NEW me -- --help | head -n1
me -- --help
$ yes-NEW -- me -- --help
me -- --help

In the gnulib patch:
> +   if RESET_OPTIND=false, optind is left as-is (suitable for programs
> +   which do not process further optional parameters (but could still

s/optional/option/

> +   process parameters directly by examining argv[optind]).  */

In the coreutils patch:

> For select programs which accept only --help and --version options
> (in addition to non-options arguments), process these options before

s/non-options/non-option/

> any other options.

Also, all coreutils callers pass reset_optind==false; does the gnulib
interface still need to provide a reset_optind parameter, given that
setting the parameter true forces reliance on the getopt-gnu module as
currently coded?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org





reply via email to

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