Lustre Script Coding Style

Bash Style
local mybool=false        # or true if ${mybool}; then do_stuff fi
 * Bash is a programming language. It includes functions.  Shell code outside of functions is effectively code in an implicit main function.  An entire function should be fully seen on one page (~70-90 lines) and be readily comprehensible.  If you have any doubts, then it is too complicated.  Make it easier to understand by separating it into subroutines.
 * The total length of a line (including comment) must not exceed 80 characters. Take advantage of bash's   operator for constants or linefeed escapes.
 * Lines can be split without the need for a linefeed escape after,  ,   and   operators.
 * The indentation must 8-column tabs and not spaces. For line continuation, an additional tab should be used to indent the continued line.
 * Comments are just as important in a shell script as in C code.
 * Use  instead of   for subshell, but avoid them if you can.  Text results from functions should be put into a well-named variable.  Use the subshell syntax only when you have to (e.g. when you need to capture the output of a separate program).  Using the construct with functions leads to stray output and/or convoluted code struggling to avoid output pollution.  It is also more computationally efficient to not fork the BASH process. BASH is slow enough already.    is obsolete and   is easier to see the start and end of the subshell command, avoids confusion with   and a small font, and   can be nested.
 * If a variable is intended to be used as a boolean, then it must be assigned as followed:
 * Use  instead of   for clarity and simplicity
 * Use  instead of , especially since the   test understands regular expression matching with the   operator.  The easiest way to use it is by putting the RE in a variable and expanding the RE after the operator without quotes.
 * Use  for arithmetic expressions instead of

Variables

 * Names of variables local to current script which are not exported to the environment should be declared with "local" and use lowercase letters
 * Names of global variables or variables that exported to the environment should be uppercase letters

Functions

 * Each function must have a section describing what it does and explain the list of parameters
 * 1) One line description of this function's purpose
 * 2) More detailed description of what the function is doing if necessary
 * 3) usage: function_name [--option argument] {required_argument} ...
 * 4) option: meaning of "option" and its argument
 * 5) required_argument: meaning of "required_argument"
 * 6) expected output and/or return value(s)
 * 1) required_argument: meaning of "required_argument"
 * 2) expected output and/or return value(s)
 * 1) expected output and/or return value(s)

Tests and Libraries

 * To avoid clustering a single  file, there should be a   file for each test that contains specific functions and variables for that test.
 * Any functions, variables that global to all tests should be put in
 * A test file only need to source  and necessary   file