Re: getopts doesn't update OPTIND when called from function

[Roman Neuhauser <neuhauser@xxxxxxxxxx>]

# schaefer@xxxxxxxxxxxxxxxx / 2015-06-06 09:46:41 -0700:
> On Jun 5,  8:46am, Roman Neuhauser wrote:
> } this diff shows how zsh (5.0.7, emulate -R sh) differs from other shells,
> } and the standard IIUC:
> 
> I believe this was previously discussed here:
> 
>   http://www.zsh.org/mla/workers//2015/msg00196.html
> 
> The key text:
> 
> > In zsh, if you add a SECOND call to getopts in the example function,
> > you will find that the second call DOES exit with a value of 1, and
> > that WHEN zsh getopts exits with a return value greater than zero,
> > THEN the value of OPTIND is set as POSIX specifies.
> 
> No one responded with an opinion of whether this conforms to the literal
> specification or not.

yeah, sorry.  i missed that conversation.

anyway, it seems perfectly unambiguous to me.  the spec[*] says

> Each time it is invoked, the getopts utility shall place the value of
> the next option in the shell variable specified by the name operand
> and the index of the next argument to be processed in the shell
> variable OPTIND.

*Each time* it is invoked ... shall place ... the index of *the next*
argument ... in ... OPTIND.

in zsh, OPTIND has the index of the last processed option instead, until
"the end of options is encountered".  so that's one clear violation of
the spec.

> When the end of options is encountered, the getopts utility shall exit
> with a return value greater than zero; the shell variable OPTIND shall
> be set to the index of the first operand, or the value "$#" +1 if
> there are no operands; the name variable shall be set to the
> <question-mark> character.

When the end of options is encountered ... the name variable shall be
set to the <question-mark> character.

in zsh, the name parameter has the value of the last processed option
instead.  that's another clear violation.

[*] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html

-- 
roman