Re: [BUG] getopts OPTIND

[Francisco de Zuviría Allende <franciscodezuviria@xxxxxxxxx>]

Such quick, much wow!

On Jan 9, 2018 8:58 PM, "dana" <dana@xxxxxxx> wrote:
>
> On 9 Jan 2018, at 16:57, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >There's a whole thread from 2015 related to this, beginning with workers/35317
>

OK, I just read workers/35317
and also the previous thread http://www.zsh.org/mla/workers//2015/msg00196.html
and also the previous from 2007 http://www.zsh.org/mla/users/2007/msg01191.html

2 key responses from Peter Stephenson:

2007:

>     This is the way you'd normally use it:  you don't know how many options
>    there are, if any, until getopts returns 1.
>
>     However, it's still a bit fishy.  The internal option index handling logic
>     has always been a bit curious; I've lost count of the number of bugs we've
>     had in it.

And also

On Thu, 28 May 2015 18:17:40 +0100
Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:

> This is documented behaviour (well, sort of -- the documentation didn't
> say quite what we actually do) so this needs another compatibility fix.
> POSIX_BUILTINS seems appropriate.

(and then submits a cool patch)

I checked man zshbuiltins

       getopts optstring name [ arg ... ]
(...)
              The first option to be examined may be changed by
explicitly assigning to OPTIND.  OPTIND has an initial  value  of
             1,  and  is  normally  set  to  1  upon  entry  to a
shell function and restored upon exit (this is disabled by the
             POSIX_BUILTINS option).

and man zshoptions

       POSIX_BUILTINS <K> <S>
(...)
              Furthermore, the getopts builtin behaves in a
POSIX-compatible fashion in that the associated  variable  OPTIND  is
             not made local to functions.


Now here things get funky. If I try this:

(
    testfunc() {
        echo POSIX_BUILTINS is $options[posixbuiltins]
        echo $*;
        for i in 1 2 3 4; do
            echo "OPTIND is $OPTIND, `(shift "$(($OPTIND - 1))"; echo
next $1)`";
            echo 'I do getopts :a: varname'; getopts ':a:' varname;
        done
    }

    (
        setopt POSIX_BUILTINS
        testfunc -a -w -e -r
    )
    (
        unsetopt POSIX_BUILTINS
        testfunc -a -w -e -r
    )
)

I get:

POSIX_BUILTINS is on
-a -w -e -r
OPTIND is 1, next -a
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 4, next -r
I do getopts :a: varname
POSIX_BUILTINS is off
-a -w -e -r
OPTIND is 1, next -a
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 4, next -r
I do getopts :a: varname

hmmmmmmm... I's it a bug?

> Well, i'm not sure about POSIX correctness, but for whatever it's worth, i can
> confirm that all of the following are in agreement as to how it should behave:
>
> ash (BusyBox)
> bash
> dash
> ksh93
> mksh
> posh
>

I think there are 2 things to discuss, one is this (possible) bug.
The other is if POSIX_BUILTINS should be on by default or not.
If off by default, New users will get bugs in their code if they
migrate from bash
If on by default, downstream projects will get bugs in their working code

This options does other things as well:

              When this option is set the command builtin can be used
to execute shell builtin commands.   Parameter  assignments
             specified  before  shell  functions  and  special
builtins are kept after the command completes unless the special
             builtin is prefixed with the command builtin.  Special
builtins are ., :, break,  continue,  declare,  eval,  exit,
             export, integer, local, readonly, return, set, shift,
source, times, trap and unset.

             In  addition,  various error conditions associated with
the above builtins or exec cause a non-interactive shell to
             exit and an interactive shell to return to its top-level
processing.

So this is a broather subject and may be better discussed in a new
thread with a suitable title