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: Sat, 12 Jan 2019 09:42:46 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 1/11/19 6:23 PM, Assaf Gordon wrote:

> For the gnulib patch, I believe the following is needed:
> ====
> diff --git a/lib/long-options.c b/lib/long-options.c
> index 52ef1f2f8..9567d5135 100644
> --- a/lib/long-options.c
> +++ b/lib/long-options.c
> @@ -139,7 +139,7 @@ parse_gnu_standard_options_only (int argc,
>    /* Restore previous value.  */
>    opterr = saved_opterr;
> 
> -  /* Reset this to zero so that getopt internals get initialized from
> +  /* Reset this to one so that getopt internals get initialized from
>       the probably-new parameters when/if getopt is called later.  */
> -  optind = 0;
> +  optind = 1;

Ouch. You're hitting the portability problem of the difference between
BSD and glibc.

>  }
> ====
> 
> Otherwise many things fail like so:
> 
>   $ ./src/dd
>   ./src/dd: unrecognized operand ‘./src/dd’
>   Try './src/dd --help' for more information.

That's the symptoms on BSD for optind = 0 (there, you HAVE to use
optreset=optind=1 for a complete reset; or plain optind=1 for a soft
reset where the man page is not clear if it will always work).  But on
glibc, optind=1 does a soft reset (works if the optstring does not start
with '-' or '+' and if you did not change POSIXLY_CORRECT), but MUST use
optind = 0 if you want a hard reset.

But shouldn't the real solution be using the gnulib module getopt-gnu
(instead of getopt-posix), so that you are guaranteed that optind=0
works and you don't have to worry about optreset?

-- 
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]