using getopts

[Arkhan]

with it, $OPTARG is the next argument to be dealt with and $OPTIND is the index of that argument........ how do I handle this case where 3 arguments need to be passed to one script?

Ive tried $(( OPTARG+1 )) for example, but that just increments the number in OPTARG by one. I tried shift $OPTIND-1 but that did not do much for me since doing so doesnt change OPTARG's value.........ive tried a few other things that did not work and were similar in outcome.

if you're able to help guide me through getting a getopts case to handle 3 arguments, please do! Ive run out of ideas with it.


thanks!

[Cabhan]

A quick Google for "Bash getopts" came across this:
Getopt and getopts

They have a few examples there. Try looking at those, and see if that helps you at all. If they don't, explain exactly what your problem is.

Also, I think that you are misunderstanding $OPTARG. This is the argument to the option you're currently looking at. You use a while loop to go through all of the arguments.

[Arkhan]

someone pointed out this exact same example to me....... I had read it last night and it didnt click...

i just type -r "2 6 9" <<<Note the ""'s

it works PERFECT........... with the quotes.

I can't believe that was the whole problem.....!

is there a proper way to get it to do the same without the quotes? or do you need the quotes when doing multiple args between options with getopts?

say you do -r 2 6 9 with no quotes. is this what the example does the shift OPTIND-1 for?

or is this what you mean by while looping through them?... if so, I am not so sure about how to set that while loop up.... what conditions would i be using for the loop?

[Arkhan]

OK duders, one final hurder I have encountered...

#! /bin/bash

while getopts r:f:c: o
do case "$o" in
	r)sh right.s $OPTARG;;
	f)sh findtext.s $OPTARG;;
	c)sh count.s $OPTARG;;
	?)echo "Useage: -r ''[#] [#] [#]'' "
		echo "	-f ''[key] [filename]''"
		echo "	-c ''[filename]''";;
esac
done

when it hits an unknown command, if that unknown command is passed arguments, it automatically exits the program........instead of pressing on. How come? If i dont pass args it works fine....

[Cabhan]

So the thing with the quotes is this:

When you type something into Bash, it separates each series of characters by spaces. This makes sense: how else would it know which part the executable is, what arg 1 is, etc.

If you want to have a single argument contain a space, you need to either escape the space (by preceding it with a '\') or put the whole thing in quotes. So in the following:

./foo arg1 arg2 arg3

We invoke ./foo with three arguments. In this:

./foo "arg1 arg2 arg3"

We have invoked ./foo with ONE argument, which happens to contain spaces.

I hope that this makes sense.

As for the shift OPTIND thing: I see it in the comments of the document I linked you, but I'm not sure what it's supposed to do. What are you trying to accomplish with it?

As for the next question, I'm not sure. Add an echo statement after the loop and see if it actually exits the program (indicating a kill by getopts: I don't expect that this is the case), or just exits the loop (in which case getopts thinks that it's done with the arguments).

I expect that getopts is done with the arguments. The older style of doing arguments is that the first non-argument signifies the end of arguments, so that would make sense if getopts sees something it thinks is a non-option, and then stops looking for options.

[Arkhan]

So the thing with the quotes is this:

When you type something into Bash, it separates each series of characters by spaces. This makes sense: how else would it know which part the executable is, what arg 1 is, etc.

If you want to have a single argument contain a space, you need to either escape the space (by preceding it with a '\') or put the whole thing in quotes. So in the following:

./foo arg1 arg2 arg3

We invoke ./foo with three arguments. In this:

./foo "arg1 arg2 arg3"

We have invoked ./foo with ONE argument, which happens to contain spaces.

I hope that this makes sense.

As for the shift OPTIND thing: I see it in the comments of the document I linked you, but I'm not sure what it's supposed to do. What are you trying to accomplish with it?

As for the next question, I'm not sure. Add an echo statement after the loop and see if it actually exits the program (indicating a kill by getopts: I don't expect that this is the case), or just exits the loop (in which case getopts thinks that it's done with the arguments).

I expect that getopts is done with the arguments. The older style of doing arguments is that the first non-argument signifies the end of arguments, so that would make sense if getopts sees something it thinks is a non-option, and then stops looking for options.

well the thing is if i chain like, 5 bad options together it will say they are all bad. it recognizes them ..... so I dont understand why it wont pickup good options after bad ones......

I shift OPTIND just one shift :

shift $(($OPTIND))

and dump $* outside the loop and it shows the rest of the listing of stuff that SHOULD be run through........but it just kicks back to the prompt instead.......

like

-b 9423 234234 2323 -x -b 39 23

will say "illegal option --x" and then the dump does indeed show -b 39 23 afterwards....... i tried a continue command, and that did nothing, and then I foundout that goto doesn't exist.....

so I really am out of ideas for how to get it to continue onward after a bad command.....

I suppose it does make sense that it terminates after a bad command though. Most programs, you dont really want continuation after a bad command....

[Cabhan]

So wait...getopts stops working after it sees bad options? Or it stops once it sees a bad option with an argument?

If the former, I'm not sure. If the latter, then it sees a bad option, and then a non-option (the argument, but since the option was illegal, Bash doesn't know that this was supposed to be an argument), which would end the chain of arguments (remember what I said before about ending on the first non-option). I've not actually used getopts before, so this is speculation.

As for the shifting thing, the point of shifting by $OPTIND is to eliminate the options. Do you know what shift does?

So your parameters all come in as $1, $2, $3, etc. The "shift" command basically moves them all down one. The old $3 becomes $2, the old $2 becomes $1, and the old $1 disappears. This is an easy way to go through all arguments. If you give shift an argument (as in shift $[OPTIND-1]), then it shifts that many arguments.

So basically, I believe that my suspicions about stopping at the first non-option are correct. Once you've looped through everything up to the first non-option, $OPTIND is pointing at the first non-option. You then run "shift $[OPTIND-1]", and this clears out everything before this. Now $1 is pointing to the first non-option, and you can start processing actual arguments to your script.

So basically, you should only be shifting _AFTER_ the getopts loop, so that you can see what comes next.

Does this make sense?

[drl]

Hi.

Is the goal here to use getotps specifically, or to process arguments?

If the former, then have you read the man page for bash? A quick way of viewing documentation for bash built-ins to use help:

help getopts

You can set variable OPTERR to continue after some errors if you supply additional code to process a case of "?". The catch is that some errors are not all errors. I've tried using OPTERR in a test script and one can continue processing after an option is found that is not in the allowable set. However, if a non-option is found, the option processing stops. I see getopts as a convenience, not an oracle, so I don't expect it to handle every situation, only the most common situations.

An older thread (http://www.linuxforums.org/forum/lin...tml#post405138) noted that getopts is not completely general (e.g. it doesn't deal with the GNU --option style of options), and some posters there went on to write their own options processing code.

The Solaris man intro page provides a number of guidelines for commands. One is:

         8.   Groups of option-arguments following an option must
              either  be  separated by commas or separated by tab
              or space  character  and  quoted  (-o  xxx,z,yy  or
              -o"xxx z yy").

I have used both styles in my own scripts, and each brings with it its own baggage ... cheers, drl

[Arkhan]

Well I found that getopts processed options, so I used it to handle my problem...

Ive tried shifting, but the only problem is, if it gets a bad option, it exits the loop, then I shift the args, but im outside of the processing loop, so what do I do?....

I passed OPTARG to each script within the getopts loop to process their stuff....

[Cabhan]

Right. You only shift outside of the loop. Not inside.

The reason for this is that getopts probably uses some sort of internal counter to go through the arguments, and shifting will mess that up (it tries to read $3, but you've shifted, so it reads the old $4 and misses the old $3 entirely).

If you shift after a bad option has made you exit the loop, it will still be purged.

Does this all make sense?