> > > However, this also loops endlessly. The reason is most likely that bash
> > > maintains an additional internal variable holding the index of the
> > > current character, relative to the current word. While this variable is
> > > not directly accessible by the user, it is set to 0 whenever OPTIND is
> > > assigned a value.
> > [...]
> >
> > That would be a bug in bash in my opinion. If OPTIND is marked
> > local to the function, it shouldn't affect the behavior of
> > parent contexts.
> >
> > Note that that bug is also in ksh93, pdksh, mksh and posh
> > (though slightly different in that one), but not in ash nor zsh.
> >
>
> Seems like ksh93 (tested with version 93u 2011-02-08) implicitly declares
> OPTIND and OPTARG in functions defined in the `function NAME {}' syntax and
> everything works fine. But if OPTIND or OPTARG are explicitly declared as
> local it may not work as expected.
>
> Wish Chet would consider fixing this problem in future bash releases. :)
Bash doesn't have the `posix' and `non-posix' distinction between function
syntax that ksh93 makes. All variables are global unless explicitly
declared as local. The other thing that Posix requires is that setting
OPTIND to 1 resets getopts' internal state. I'll take another look and
see if I can work around the issue: resetting getopts when returning from
the shell function restores the value `1' (since we're still processing
the first argument), which causes getopts' internal state to reset.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
