Here's my five penn'orth. A bash script (actually any program!!) should:
Use getopt(1) to process command line arguments. There are many good reasons for this. Just do it. Let me count (some of) the ways:
foobar -s -f -t == foobar -sft
–to terminate options
Even better, use my getopt(1) wrapper 2-argp.sh which is kinda sorta like GNU's argp(3) in glibc. It gives you a single place to define options which is then used to:
Always provide long options as well as single letter options - they're more mnemonic for infrequent users and provide valuable documentation when scripted.
respond to the -h, –help option with a usage message to !!!STDOUT!!! and exit 0. This help should be available no matter what the machine's state - so issue it before looking for dependencies and without making assumptions about what is installed.
If there are specific dependencies, then make sure they are documented in the help message.
provide a way to get the program's version eg -V, –version to !!!STDOUT!!! and exit 0
Note that -h and -V processing should happen before any other substantial processing or checking is done - make sure -h can always be done no matter what
Error messages should go to !!!STDERR!!! - do not print the usage as it just fills the screen and hides the meat of the error. At the most, refer the user to the usage page with
run 'foobar -h' for help or 'man foobar' for a reference manual.
non-zero exit on any error
execute as silently as possible so the user doesn't have to scour through copious output. If feedback on progress is needed, just “echo -n .”
The exception, of course, is if a verbosity command is given, generally with -v, –verbose - and the output goes to stdout, thank you very much (so we can distinguish bash's own -x output which goes to stderr)
include a man page if non-trivial
always include the crunchbang as the first line:
#! /usr/bin/env bash
use subroutines heavily - only put the following in the mainline:
initialise process_options "$@" main "$@"