User Tools

Site Tools


unixscripts:3-decentbash

This is an old revision of the document!


Here's my five penn'orth. A bash script (actually any program!!) should:

  • use getopt(1) to process arguments. There are many good reasons for this. Just do it. Let me count (some of) the ways:
    • provides a rational, predictable user interface - compare the nasty old peculiarities of tar and find!!
    • supports short option merging eg foobar -s -f -t == foobar -sft
    • disambiguates option argument spacing eg foobar -z1 == foobar -z 1
    • re-orders options so they can be processed and then popped and forgotten
    • supports to terminate options
    • plain old simple works - why write bug-prone new code when getopt(1) just works?
  • Even better, use my getopt(1) wrapper argp.sh.
    • a single place to define options which is then used to:
      • create the getopt(1) command line,
      • process the options setting appropriate environment parameters
      • print help & man pages without any extra code
      • honours GNU's ARGP_HELP_FMT environment variable
      • is pretty similar to GNU's argp(3) getopt(3) wrapper in glibc
      • further reduces the chance of bugs arising - particularly as the script is maintained
      • increase the chance that help and man pages are actually written
  • 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
  • provide a way to get the program's version eg -V/–version to !!!STDOUT!!! and exit 0
  • -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 "$@"
unixscripts/3-decentbash.1451555791.txt.gz · Last modified: 2015/12/31 02:56 by admin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki