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
