Scripting standards

These are some general guidelines for creating and editing shell scripts for Genome Browser engineers. Some items are specific to bash; most apply to bash and tcsh (or csh, ksh, etc.). As with all genomewiki pages, editing and adding to this page is encouraged.

Send errors to stderr

This is way easier to do in bash than in tcsh:

Set options in bash scripts

It's a good idea to add set -eEu -o pipefail near the top of most bash scripts. These options mean:

• -e exit immediately if a simple command fails
• -E inherit error trap functions
• -u treat unset variables as errors rather than expanding them to be empty variables
• -o pipefail if this option isn't set, pipelines will have the exit status of only the right-most command. If it is set, and one of the commands in the middle of a pipeline fails, the whole pipeline will fail.

- exit 0 at the end of a successful script, exit non-zero if a problem is encountered

- use functions; we should consider making bash function library files

- keep functions short. If any function (in any language) is longer than 15 or so lines, it probably needs to be broken into other functions. Ask Markd if you think you have a good case for a longer function.

- use meaningful variable and function names - put machine names in qaConfig.csh and qaConfig.bash

- trap kill signals and clean up your mess

- use PIDs $$ .. . could also put files into /tmp (or ask admins where best place is)

- make scripts composeable . . . the output of one program could become input in another program

- make self-documenting code: choose meaningful variable and function names, even if they are kind of long. Don't add gratuitous comments when it's obvious from a function name what the code does:

# check to see if the database exists
databaseExists() {
  code...
}

- no magic numbers