Small getopts tutorial

incomplete

When you want to parse commandline arguments in a professional way, getopts is the tool of choice. Unlike its older brother getopt (note the missing s!), it's a shell builtin command. The advantage is

• you don't need to hand your positional parameters through to an external program
• getopts can easily set shell variables you can use for parsing (impossible for an external process!)
• you don't have to argue with several getopt implementations which had buggy concepts in the past (whitespaces, ...)
• getopts is defined in POSIX®

Some other methods to parse positional parameters (without getopt(s)) are described in: How to handle positional parameters.

Note that getopts is not able to parse GNU-style long options (--myoption) or XF86-style long options (-myoption)!

It's useful to know what we're talking about here, so let's see... Consider the following commandline:

mybackup -x -f /etc/mybackup.conf -r ./foo.txt ./bar.txt

• -x is an option, a flag, a switch: one character, indroduced by a dash (-)
• -f is also an option, but this option has an additional argument (argument to the option -f): /etc/mybackup.conf. This argument is usually separated from its option (by a whitespace or any other splitting character) but that's not a must, -f/etc/mybackup.conf is valid.
• -r depends on the configuration. In this example, -r doesn't take arguments, so it's a standalone option, like -x
• ./foo.txt and ./bar.txt are remaining arguments without any option related. These often are used as mass-arguments (like for example the filenames you specify for cp(1)) or for arguments that don't need an option to be recognized because of the intended behaviour of the program (like the filename argument you give your text-editor to open and display - why would one need an extra switch for that?). POSIX® calls them operands.

To give you an idea about why getopts is useful: The above commandline could also read like...

mybackup -xrf /etc/mybackup.conf ./foo.txt ./bar.txt

The option flags can be upper- and lowercase characters, and of course digits. It may recognize other characters, but that's not recommended (usability and maybe problems with special characters).

In general you need to call getopts several times. Each time it will use "the next" positional parameter (and a possible argument), if parsable, and provide it to you. getopts will not change the positional parameter set — if you want to shift it, you have to do it manually after processing:

shift $((OPTIND-1))
# now do something with $@

Since getopts will set an exit status of FALSE when there's nothing left to parse, it's easy to use it in a while-loop:

while getopts ...; do
  ...
done

getopts will parse options and their possible arguments. It will stop parsing on the first non-option argument (a string that doesn't begin with a hyphen (-) that isn't an argument for any option infront of it). It will also stop parsing when it sees the -- (double-hyphen), which means "end of options".

getopts also uses these variables for error reporting (they're set to value-combinations which arent possible in normal operation).

The base-syntax for getopts is:

getopts OPTSTRING VARNAME [ARGS...]

The option-string tells getopts which options to expect and which of them must have an argument. The syntax is very simple — every option character is simply named as is, this example-string would tell getopts to look for -f, -A and -x:

getopts fAx VARNAME

When you want getopts to expect an argument for an option, just place a : (colon) after the proper option flag. If you want -A to expect an argument (i.e. to become -A SOMETHING) just do:

getopts fA:x VARNAME

If the very first character of the option-string is a : (colon), which normally would be nonsense because there's no option letter preceeding it, getopts switches to the mode "silent error reporting". In productive scripts, this is usually what you want (handle errors yourself and don't get disturbed by annoying messages).

The getopts utility parses the positional parameters of the current shell or function by default (which means it parses "$@").

You can give your own set of arguments to the utility to parse. Whenever additional arguments are given after the VARNAME parameter, getopts doesn't try to parse the positional parameters, but these given words.

This way, you are able to parse any option set you like, here for example from an array:

while getopts :f:h opt "${MY_OWN_SET[@]}"; do
  ...
done

A call to getopts without these additional arguments is equivalent to explicitly calling it with "$@":

getopts ... "$@"

Regarding error-reporting, there are two modes getopts can run in:

• verbose mode
• silent mode

For productive scripts I recommend to use the silent mode, since everything looks more professional, when you don't see annoying standard messages. Also it's easier to handle, since the failure cases are indicated in an easier way.

Enough said - action!

Let's play with a very simple case: Only one option (-a) expected, without any arguments. Also we disable the verbose error handling by preceeding the whole option string with a colon (:):

#!/bin/bash
 
while getopts ":a" opt; do
  case $opt in
    a)
      echo "-a was triggered!" >&2
      ;;
    \?)
      echo "Invalid option: -$OPTARG" >&2
      ;;
  esac
done

Let's do some tests:

$ ./go_test.sh
$ 

$ ./go_test.sh /etc/passwd
$ 

The arguments given to your script are of course accessible as $1 - ${N}.

Now let's trigger getopts: Provide options.

First, an invalid one:

$ ./go_test.sh -b
Invalid option: -b
$ 

Now, a valid one (-a):

$ ./go_test.sh -a
-a was triggered!
$ 

Of course it's possible to mix valid and invalid options when calling:

$ ./go_test.sh -a -x -b -c
-a was triggered!
Invalid option: -x
Invalid option: -b
Invalid option: -c
$ 

Finally, it's of course possible, to give our option multiple times:

$ ./go_test.sh -a -a -a -a
-a was triggered!
-a was triggered!
-a was triggered!
-a was triggered!
$ 

The last examples lead us to some points you may consider:

• invalid options don't stop the processing: If you want to stop the script, you have to do it yourself (exit in the right place)
• multiple identical options are possible: If you want to disallow these, you have to check manually (e.g. by setting a variable or so)

Let's extend our example from above. Just a little bit:

• -a now takes an argument
• on an error, the parsing exits with exit 1

#!/bin/bash
 
while getopts ":a:" opt; do
  case $opt in
    a)
      echo "-a was triggered, Parameter: $OPTARG" >&2
      ;;
    \?)
      echo "Invalid option: -$OPTARG" >&2
      exit 1
      ;;
    :)
      echo "Option -$OPTARG requires an argument." >&2
      exit 1
      ;;
  esac
done

Let's do the very same tests we did in the last example:

$ ./go_test.sh
$ 

$ ./go_test.sh /etc/passwd
$ 

Invalid option:

$ ./go_test.sh -b
Invalid option: -b
$ 

Valid option, but without the mandatory argument:

$ ./go_test.sh -a
Option -a requires an argument.
$ 

Let's provide the argument:

$ ./go_test.sh -a /etc/passwd
-a was triggered, Parameter: /etc/passwd
$

• Internal: Handling positional parameters
• Internal: The case statement
• Internal: The while-loop