[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Nested calls to getopts incorrectly parses clustered options
From: |
Øyvind Hvidsten |
Subject: |
Nested calls to getopts incorrectly parses clustered options |
Date: |
Sat, 31 May 2014 18:40:30 +0200 |
User-agent: |
Cathedral Secure Mail v0.8 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Nested calls to getopts incorrectly parses clustered options,
Øyvind Hvidsten <=