Command-Line Processing with 'process-getopt'
By Bob Hepple
You know you oughta...
... make your bash(1) scripts as pretty as your C code, but somehow there's
never time. If it's just for your own use, then maybe you don't care -
until you forget what foobar
does, and you try foobar
-h
. Uh oh, yes, now I remember: -h
stands for "halt".
Whoops.
This article explains a simple way to spruce up your scripts so that they act predictably in the Unix way concerning options and arguments. But first of all, a little discussion of the problems the bash(1) developer faces.
When it does matter, when other people are going to be using your script, or when you can't rely on your own memory (don't worry, it'll happen to you too one day), it's a pain to code responses in bash(1) to all the possible inputs that people can make. Other people can be pretty inventive in breaking things with syntax you never imagined.
Then there's the matter of standards: Did you even know that there's a GNU standard for this kind of stuff?
For example, does your script support long options (--verbose
)
as well as short ones (-V
)? Long options are great for making
scripts self-documenting, short ones for power users (and those of us still
typing on glass teletypes).
Is your script flexible about spacing around option arguments? e.g.,
-n 123
should be equivalent to -n123
and to
--number 123
and --number=123
.
Can long options be given as the smallest unique substring, e.g.,
--numb
as a shorthand for --number
?
Can you fold short options together, e.g., -t -s -u
as
-tsu
?
Does -h, --help
consistently display help (to stdout, thank
you very much, so that the user can pipe it into a pager program like
less(1))?
How about -v,--verbose
or -V, --version
? ... and
so on. These are all things that users (OK, Unix-savvy users) expect - so
adhering to these conventions makes everyone's life easier.
But it's really quite tedious and surprisingly hard to get all this right when you write your own bash(1) code, and it's not surprising that so few scripts end up being user-hardened.
Where it really hurts is when you try to maintain that bash(1) code. Even with getopt(1) this can be a pain (actually the syntax for getopt(1) itself is pretty arcane), because the getopt(1) command structure requires you to repeat the option letters and strings in three places:
- the call to getopt(1)
- the case statement to process the options
- the help and man(1) pages.
This repetition introduces wide margins for bugs to creep into the code.
A solution
In compiled languages, there are wrapper functions to put around getopt(3) that help considerably in reducing the labour and opportunity for error, in writing this sort of code. They include GNU's own argp(3) and Red Hat's popt(3).
In python(1) you can use OptionParse.
For bash(1) scripts, there hasn't been anything since getoptx(1) died out - but, in all my own scripts for the past few years, I've been using a library that I wrote: process-getopt(1). It's a wrapper around getopt(1) that makes life considerably easier for bash(1) scripters, maintainers, and users.
As an example, here's a tiny script that uses it to process its command line:
#!/bin/bash PROG=$(basename $0) VERSION="1" USAGE="A tiny example" # call process-getopt functions to define some options: source ./process-getopt SLOT_func() { [ "$1" ] && SLOT="yes"; } # callback for SLOT option add_opt SLOT "boolean option" s "" slot TOKEN_func() { [ "$1" ] && TOKEN="$2"; } # callback for TOKEN option add_opt TOKEN "this option takes a value" t n token number add_std_opts # define the standard options --help etc: # The next 4 lines call the callbacks and remove the options from the command line: TEMP=$(call_getopt "$@") || exit 1 eval set -- "$TEMP" process_opts "$@" shift "$?" # remove the options from the command line # The hard lifting is done - $@ just contains our arguments: echo "SLOT=$SLOT" echo "TOKEN=$TOKEN" echo "args=$@"
... and you're done. Here's the sort of output you get without any further coding:
$ tiny --help Usage: tiny [-shVvq-] [--slot --help --version --verbose --quiet] [-t,--token= ] A tiny example Options: -s, --slot boolean option -t n, --token=number this option takes a value -h, --help print this help and exit -V, --version print version and exit -v, --verbose do it verbosely -q, --quiet do it quietly (negates -v) -- explicitly ends the options
Here's an example of using the options and arguments on the command line:
$ tiny -s --token="my token" arg1 arg2 SLOT=yes TOKEN=my token args=arg1 arg2
process-getopt(1) works with bash-2.04 and later and lives at:
http://sourceforge.net/projects/process-getopt
It's pretty easy to convert your existing scripts to use process-getopt(1): Follow the samples and manuals here:
http://bhepple.freeshell.org/oddmuse/wiki.cgi/process-getopt
Here's a direct link to the manual:
http://bhepple.freeshell.org/scripts/process-getopt.pdf
Enjoy!
Talkback: Discuss this article with The Answer Gang
Bob Hepple is the youngest grumpy old man at Promptu Corp on the Gold Coast in Australia and earned his UNIX stripes at Hewlett-Packard in 1981. Since then he's worked in Asia and Australia for various UNIX vendors and crypto companies - but always in UNIX and GNU/Linux.
Originally a Geordie land-surveyor, he now thinks he's dinky-di after 30 years of Oz - but apparently the pommie accent gives the game away.