On Wed, Jan 14, 2015 at 12:35 PM, Øyvind 'bolt' Hvidsten <b...@dhampir.no>
wrote:
> Nobody else having issues with this?
> It's still a case in bash 4.3.30
>
>
> On 31/05/14 18:40, Øyvind Hvidsten wrote:
>
>> For a simple test:
>>
>> $ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
>> do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -a -b -c; fi; done;
>> }; f -x -y -z
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: z
>>
>> However, if the options are clustered:
>> $ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
>> do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -abc; fi; done; }; f
>> -xyz
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> etc....
>>
>> It's important to note that this happens even if f() doesn't call
>> itself, but rather calls some other function that also uses getopts. The
>> clustering of the inner set of options (-abc) is also not important -
>> the internal index of $1 is reset to the beginning either way.
>>
>> Whatever variable tracks the index within a single clustered set of
>> options should probably also be exposed as a shell variable so it can be
>> set as local to the function. Or it should be so implicitly.
>>
>>
>> Øyvind
>>
>>
>>
>
>
it has been reported before, I guess chet didn't manage to work around it
yet
http://lists.gnu.org/archive/html/bug-bash/2012-01/msg00044.html
