Re: PATCH: 3.1.6-pws-3: more getopts bugs

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Sep 10, 11:21am, Peter Stephenson wrote:
} Subject: PATCH: 3.1.6-pws-3: more getopts bugs
}
} 1. The counter for how far we are into a single option argument doesn't get
} rest when OPTIND goes back to 1 (i.e. when a new function is started), only
} if OPTIND is set explicitly to 0.  (How can this possibly have escaped
} notice for almost a decade?)

It went unnoticed because it was introduced in January of 1998 when Zefram
"Rewrote getopts to remove its various bugs."  (Or so says ChangeLog.)  It
is not present in 3.0.6 (try your "badfn" test case).

} 2. The manual page claims the option variable gets set to '?' even if an
} error message was printed by getopts itself (i.e. no initial colon).  Guess
} what?  To see that, remove the : and watch the second line not get
} executed.

This also works as expected in 3.0.6.  I wonder what bugs Zefram removed?

Anyway, as this works in 3.0.6 with optcind static to bin_getopts(), I
wonder whether saving/restoring optcind in exec.c is in fact the right
thing.  The diffs in bin_getopts() from 3.0.6 to 3.1.6 are so extensive
that I'm not immediately able to discern what's happening differently.
It looks like maybe the 3.0 code resets optcind before returning end of
options, whereas the 3.1 code sets it on entry to the function iff the
user has set OPTIND=0.

Restarting on OPTIND=0 must be one of the bugs Zefram fixed, but maybe
he shouldn't have taken out the reset of optcind upon failure return?


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com