On 1/14/15 5:35 AM, Øyvind 'bolt' Hvidsten wrote:
> Nobody else having issues with this?
> It's still a case in bash 4.3.30
There is a change in the devel branch that makes local copies of OPTIND
behave as you expect.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On Wed, Jan 14, 2015 at 12:35 PM, Øyvind 'bolt' Hvidsten
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
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
o
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
