I need to use getopts sooner (and more often) in Bourne shell scripts

March 11, 2016

I have this flaw in my Bourne shell scripting; in shell scripts and shell scripts alone, I find it all too easy and tempting to reach for ad-hoc option processing when I add the first option to a script. Inevitably, handling the first option will look something like:

[...]
SOMEVAR=0
if [ "$1" = "-L" ]; then
   SOMEVAR=1; shift
fi
[...]

When a second option shows up, it sometimes winds up getting wedged awkwardly into the same sort of code. Maybe the options conflict so they'll never get used together in practice, or I'll tell myself that I'll always remember the order, or some equally bad excuse.

Doing this is a mistake, and I need to accept that. Rather than ever writing ad-hoc option processing code, I should be using getopts in my scripts right from the start even in tiny little scripts. Even using getopts for a single option is not that much more code over the simple version above, and it has better error handling. And of course, adding more options is much simpler and works much better if I'm using getopts already.

(Probably I should just memorize and master a standard getopts stanza so I can drop it into everything by reflex. But that's going to take time, and also not reflexively reaching for the quick solution for single options.)

I'm not entirely sure why I'm so reluctant in practice to use getopts, but for whatever reason it's not part of my shell landscape most of the time. This is silly, as getopts has existed for a long time and is a Single Unix Specification standard. As a practical matter it's long since been supported everywhere that I'm ever going to run a shell script. I need to get with the times and update my Bourne shell habits.

(This entry is brought to you by me updating some scripts today, trying to add a second option to them in a terrible way, and then telling myself that I should be doing this right and switching them over to using getopts. The resulting shell script code is both better and shorter.)


Comments on this page:

By jrw32982 at 2016-03-25 15:10:36:

Here's some boilerplate for you.

usage() {
   rc=0 && [[ $# != 0 ]] && rc=1 && exec >&2 && printf "%s\n" "${0##*/}: $*"
   /bin/cat <<EOF
usage: ${0##*/} [-a ARG] [-b] FILE...
  -a ARG  blah blah
  -b  blah blah
EOF
   exit $rc
}

opt_a=
val_a=
opt_b=
while getopts :a:b opt ;do
   case $opt in
      a) opt_a=SPECIFIED; val_a=$OPTARG ;;
      b) opt_b=SPECIFIED ;;
      :) usage "option $OPTARG requires an argument" ;;
      *) [[ $OPTARG = \? ]] && usage            # handle -?
         [[ $OPTARG = "" ]] && OPTARG=$opt      # e.g. OPTARG=+a
         usage "unrecognized option $OPTARG"    # handle [-+]NONOPTION
         ;;
   esac
done
shift $((OPTIND-1))

[[ $# = 0 ]] && usage "at least one FILE must be specified"
echo "$# args: $*"
echo "a=<$opt_a> ($val_a)"
echo "b=<$opt_b>"
exit 0
By rjc at 2016-08-30 07:41:58:

@jrw32982

This is hardly a Bourne Shell script.

Written on 11 March 2016.
« A sensible surprise (to me) in the Bourne shell's expansion of "$@"
Why it's irritating when Ubuntu packages don't include their configuration files »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Mar 11 01:16:48 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.