bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nested calls to getopts incorrectly parses clustered options


From: Pierre Gaston
Subject: Re: Nested calls to getopts incorrectly parses clustered options
Date: Wed, 14 Jan 2015 12:59:05 +0200



On Wed, Jan 14, 2015 at 12:35 PM, Øyvind 'bolt' Hvidsten <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]