Michael Greenberg <[email protected]> wrote, on 14 Jun 2019:
>
> Hi all,
>
> I'm unsure of what `getopts` should do to `OPTIND` when working with
> grouped options.
>
> Consider the following script:
>
> ```sh
> getopts "ab:c:" opt -ab hi -c hello ; printf "OPTIND=%1s opt=%1s OPTARG=%-5s
> ?=%d\n" "$OPTIND" "$opt" "$OPTARG" "$?"
> getopts "ab:c:" opt -ab hi -c hello ; printf "OPTIND=%1s opt=%1s OPTARG=%-5s
> ?=%d\n" "$OPTIND" "$opt" "$OPTARG" "$?"
> getopts "ab:c:" opt -ab hi -c hello ; printf "OPTIND=%1s opt=%1s OPTARG=%-5s
> ?=%d\n" "$OPTIND" "$opt" "$OPTARG" "$?"
> getopts "ab:c:" opt -ab hi -c hello ; printf "OPTIND=%1s opt=%1s OPTARG=%-5s
> ?=%d\n" "$OPTIND" "$opt" "$OPTARG" "$?"
> ```
>
> Existing shells seem to exhibit one of two behaviors: early and late
> incrementing. In the early-incrementing group, dash and mksh (and
> smoosh) all set OPTIND to 2, then 3, then 5. In the late-incrementing
> group, bash, zsh, and ksh set OPTIND to 1, then 3, then 5. yash seems to
> be non-conformant, setting OPTIND first to 1:2, then 3, then 5.
>
> The core issue is that the `getopts` specification (in particular, the
> mandate to allow grouped options per Utility SYntax Guideline 5) can
> only be met by tracking extra state---the offset into the current
> option. yash reveals this state, but most shells seem to keep it hidden.
>
> My question is: are both of these behaviors (the early-incrementing
> OPTIND=2 at first and the late-incrementing OPTIND=1 at first) allowed?
> One might read "the `getopts` utility shall place ... the index of the
> next argument to be processed in the shell variable `OPTIND`" and assume
> that late-incrementing is the right choice (since we're still processing
> the first argument after processing `-a`), but it's not 100% clear to me
> that's the right interpretation.
It seems to me that "the next argument to be processed" is ambiguous.
It can be taken as meaning either:
the argument to be processed by the next getopts call
which leads to the bash/ksh/zsh behaviour, or:
the argument after the one that this getopts call processed
which leads to the dash/mksh behaviour.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
