This isn't likely my final post to this thread. I have yet to re-read all the input provided above; but on what I have read, and on my experimenting, I conclude that shell getopts doesn't do what I want in every case.
I've tried a bunch of workarounds, including about 10 lines of sed expressions and a bunch of other crap to pre-process the CLI args, but it was still not working right and getting ridiculous.
I have what I think is the solution, but it won't necessarily work *exactly* like this for someone with slightly different requirements, but down below I demonstrate how it can work for that.
To summarize the problem:
My requirement was that an optional argument "R" can accept an optional numeric value, and "R" is the only option that accepts an optional value of any kind. I wanted the "R" and its value to be able to be given in *any* format on the commandline, and be interpreted correctly. This wasn't working because depending on whether R's value immediately followed "R", and/or was separated by a space, and/or was followed immediately by other options or by a space and other options, the outcome for "R" and its value were unpredictable/unreliable. I'd like to have --long-opts too, but they're a frivolity I can do without at the moment.
Making options that require arguments, require an "=" sign, was not agreeable to me. So, here's what I've got:
Code:
while getopts ":l.#vhAabcdkpPswz1234567890" OPT ${ARGV}; do
case $OPT in
l) BASENAME="no" ;;
'.') NAMEOPT="-name"; DOTOPT="*" ;;
'#') SHEBANG="yes" ;;
# v) VERBOSE='1' ;;
h) help; exit 0 ;;
A) add_shell all ;;
a) add_shell ash ;;
b) add_shell bash ;;
c) add_shell csh ;;
d) add_shell dash ;;
k) add_shell ksh ;;
p) add_shell perl ;;
P) add_shell python ;;
s) add_shell sh ;;
w) add_shell awk ;;
z) add_shell zsh ;;
[0-9]) Ropt="${Ropt}${OPT}" ;;
*) echo "Invalid parameter: -${OPTARG:-$OPT}" >&2; exit 1 ;;
esac
done
if [ -n "${Ropt}" ]; then
if [ $((${Ropt})) -ge 2 ]; then
MAXDEPTH="-maxdepth ${Ropt}"
elif [ $((${Ropt})) -eq 0 ]; then
unset MAXDEPTH
fi
fi
So, I've removed "R" as a CLI option, but have added [0-9] as CLI options. All options are given together in one string beginning with a "-".
The feature of the program that is controlled by the "R" value (we'll call it the "R part"), is still present and still has its default setting of 1. But now, it retains its default setting unless any digits are given in the CLI arg-string. Digits given on the CLI are concatenated into a (string) integer number which is then evaluated after getopts is done. If the resulting integer number is just a "0", the "R part" of the program is disabled. If the integer number is >=2 then the "R part" is adjusted accordingly.
I figure, if a person were to want to use this method for multiple "R" possibilities, it would be easy enough. Let's say it's like my situation, but you have "R" and "X", which can each take optional numeric arguments. Let's say the CLI receives:
-abR2cdX5
During the getopts loop:
1) R is found, turning a flag on. The flag says "any upcoming digits will concat onto the R string".
2) 2 is found,so Rstring:=2
3) c is found, d is found.. X is found. If R flag is on, turn it off. So Rstring=2. Turn on X flag.
4) Now any upcoming digits concat onto X string.
5) etc.. etc... eventually Rstring=2 and Xstring=5 when done looping.
So this is what I'm going to use I think. It's really simple to parse the input, and reliable. Feedback welcome! And meanwhile, thank you to everyone who has contributed here, and who adds anything further too.
nice input for getopts
That explains why you never see that operator in my code. :/
