Both “getopt” and getopts are tools to use for processing and validating shell script arguments. They are similar, but not identical. More confusingly, functionality may vary from place to place, so you need to read the man pages carefully if your usage is more than casual.
Properly handling command line arguments is difficult if you want the usage to be flexible. It’s easy to write a script that demands arguments in a specific order; much harder to allow any order at all. It’s also hard to allow bunched together arguments or spaced out to be equivalent:
These are the problems that getopt(s) are designed to handle. They ease the job considerably, but introduce their own little quirks that your script will need to deal with.
getopt
This is a standalone executable that has been around a long time. Older versions lack the ability to handle quoted arguments (foo a “this won’t work” c) and the versions that can do so clumsily. If you are running a recent Linux version, your “getopt” can do that; SCO OSR5, Mac OS X 10.2.6 and FreeBSD 4.4 has an older version that does not.
The simple use of “getopt” is shown in this mini-script:
What we have said is that any of -a, -b, -c or -d will be allowed, but that -c is followed by an argument (the “c:” says that).
If we call this “g” and try it out:
We start with two arguments, and “getopt” breaks apart the options and puts each in its own argument. It also added “–“.
Of course “getopt” doesn’t care that we didn’t use “-d”; if that were important, it would be up to your script to notice and complain. However, “getopt” will notice if we try to use a flag that wasn’t specified:
However, if you preface the option string with a colon:
“getopt” will be silent about the unwanted flag.
As noted at the beginning, if we give “getopt” arguments containing spaces, it breaks:
Not only has “foo bar” become two arguments, but they have been separated. This will be true whether you have the newer version that is capable of handling those arguments or not, because it requires different syntax to handle them. If you do have the newer “getopt”, you’d need to write the script differently:
We’ve added a “-o”, changed $* to $@ in quotes, and used an “eval” for the set. With the newer (as is on Linux) version, that works:
However, if you use that script with the older getopt, you get a useless result:
It’s unfortunately easy to get bad results from “getopt” by misquoting or using the wrong syntax. Whenever I’ve had to use this, I make sure to print out the arguments as I did in the “After getopt” while testing. Once you get it right, using it is easy:
and the results are as expected.
However, note the “Usage” section which prints if “getopt” doesn’t like what you gave it: an extra flag, or not giving an argument to a flag that requires one. Using the this newest script, we can test some of that:
But “getopt” is easily fooled:
You’d have to deal with that nastiness yourself.
getopts
sh and bash builtin. Easier to use and generally better than getopt, though of course not available in csh-like shells. You shouldn’t be using those anyway.
This works rather differently than “getopt”. First, because it’s a built-in, you usually won’t find a separate man page for it, though “help getopts” may give you what you need.
The old “getopt” is called once, and it modifies the environment as we saw above. The builtin “getopts” is called each time you want to process an argument, and it doesn’t change the original arguments . A simple script to test with:
Trying this produces good results:
The “$OPTIND” will contain the index of the argument that will be examined next. If you really needed to, you could tell from that whether arguments were bunched together or given separately, but the real point of it is to let you reset it to re-process the arguments. Try this slightly more complicated version (we’ll call it “gg”):
We’ll give it more arguments so that you can observe it at work:
The leading “:” works like it does in “getopt” to suppress errors, but “getopt” gives you more help. Back to our first simple version:
The builtin “getopts” doesn’t get fooled: the “-b” is the argument to c, but it doesn’t think that b is set also.
If “getopts” encounters an unwanted argument, and hasn’t been silenced by a leading “:”, the “$flag” in our script above will be set to “?”:
With a leading “:” (while getopts “:abc:d” flag), things are different:
If an argument is not given for a flag that needs one, “$flag” gets set to “:” and OPTARG has the misused flag. If an unknown argument is given, a “?” is put in “$flag”, and OPTARG again has the unrecognized flag.
See also Perl Getopts
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
