Hide Forgot
I have rh60 (with GNU bash, version 1.14.7(1)) + kernel 2.2.12. It seems there's a problem with getopts built-in bash function, when called from within another script which uses getopts itself: the second getopts is not evaluated if the first is. Here are two shell scripts, a1 and a2, which show the problem (bug). If you run a2 directly all is ok, if a2 is called by a1 a weird thing happens (the a2's getopts is not evaluated): === a1 === animal=dog while getopts a par do case $par in a) animal=cat ;; esac done echo $animal ./a2 -b ========= === a2 === color=white while getopts b par do case $par in b) color=black ;; esac done echo $color ========= $ ./a2 white $ ./a2 -b black $ ./a1 dog black $ ./a1 -a cat white <== WRONG, should be "black". I've a Caldera1.3 box with "GNU bash, version 1.14.7(2)" which works as expected; I took the bash from Caldera, put it on rh60 (with libc5 installed) and it has the same problem, so the real problem should be in a place different from bash, but I cannot understand where. I found out the the problem can be resolved by putting unset OPTIND at the beginning of a2, but this is not a viable solutions if you have many scripts.
We suggest that you run this script under bash2, which displays the correct behaviour. The bash (v1) behavior may or may not be easily correctable; this bug has been passed along to the bash (v1) package maintainer.
You need to put the #!/bin/bash magic at the beginning of each script. If I do that and I have the following scripts mde mode 755 the things are working okay: a1: #!/bin/bash animal=dog while getopts a par do case $par in a) animal=cat ;; esac done echo $animal ./a2 -b a2: #!/bin/bash color=white while getopts b par do case $par in b) color=black ;; esac done echo $color
*** Bug 9917 has been marked as a duplicate of this bug. ***