Bash: parsing arguments with ‘getopts’

Today I was writing some scripts, and in every script I wanted something to handle all input arguments, in a good way, so I could pass my arguments in any order and my program would know about it.

I used ‘getopts’ before, but this time I decided to write some stuff here about it.

Let me show you how useful it can be:

Let’s suppose that I’m writing a test script, that needs, as argument, the type of the test, the server, the server root password and for debugging purpose we’re going to have a verbose flag too. So, putting it down:

  • “-t” – the type of the test, let’s suppose we have “test1” and “test2”
  • “-s” – the server
  • “-p” – the root password of the server
  • “-v”– a flag just to let the script run in a verbose mode

Ok, now how we’re going to write this script and parse these arguments? We can use the harder way, fixing an order and parsing it by hand at the script, something like this:

salveti@evalap /tmp/scripts $ cat
# Argument order = -t test -r server -p password -v
if [[ $# -gt 6 ]]

Alright, this works, but if you want to run the script with the arguments in a different way? Or if you forget and put it in the right order? It’ll not work, so, this is an ugly solution.

Ok, but how can you deal with arguments not worrying about the order and if needs an argument or not? Getopts is the answer 😉

Let’s see how we can write the script using getopts and them we explain how it works.

The new script (it’s bigger, I’ll explain why):
# Argument = -t test -r server -p password -v

cat << EOF
usage: $0 options

This script run the test1 or test2 over a machine.

   -h      Show this message
   -t      Test type, can be ‘test1’ or ‘test2’
   -r      Server address
   -p      Server root password
   -v      Verbose

while getopts “ht:r:p:v” OPTION
     case $OPTION in
             exit 1

if [[ -z $TEST ]] || [[ -z $SERVER ]] || [[ -z $PASSWD ]]
     exit 1

In this script I created a usage function, just to help you explaining all arguments.

Then, we can see the getopts’ call while getopts "ht:r:p:v" OPTION, this is the main point of the script, it’s how we deal with arguments using getopts. Getopts require an optstring and a var name, just to help you checking the arguments.

When you call getopts, it will walk in your optstring argument, identifying which argument needs a value and which don’t. After getting an argument, getopts set the OPTION var, so you can check it using a case code block, or something like that. If your argument needs a value, getopts will set the var $OPTARG with the value, so you can check and see if it’s what you were expecting (in this example, check if the test argument is passed with “test1” or “test2”). Easy hã?

Ok, but what is this “:” doing in the arguments? And why the arguments “h” and “t” are together?

This is an import point of getopts. You can use “:” in two cases, one when you want getopts to deal with argument’s errors, and another to tell getopts which argument needs a value.

First, the error checking. When you pass the arguments to getopts in the optstring, getopts will only check what’s there, so if you pass an argument that’s not listed at optstring getopts will give an error (because it’s not a valid argument). When you put “:” at the beginning of the optstring, “:ht:r:p:v” for example, getopts sets the OPTION var with “?” and the $OPTARG with the wrong character, but no output will be written to standard error; otherwise, the shell variable $OPTARG will be unset and a diagnostic message will be written to standard error (./ illegal option — l, if you pass the argument -l, for example).

Second, how to tell getopts which argument needs a value. When you need an argument that needs a value, “-t test1” for example, you put the “:” right after the argument in the optstring. If your var is just a flag, withou any additional argument, just leave the var, without the “:” following it.

So, in the example, you can see that I’m leaving the error checking to getopts, the vars “t”, “r”, “p” needs a value and “v” is just a flag.

To finish the script, we have a var checking, just to see if all vars that needs a value are not empty.

And, that’s it. For now, you can try making a new script and playing with it a little, it’s not so hard and can help you very much when writing new scripts 🙂