Lustre Script Coding Style

Bash Style
local mybool=false        # or true if $mybool; then do_stuff fi for i in {1..10}; do     something_with $i done
 * 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 use 8-column tabs and not spaces. For line continuation, an additional tab should be used to indent the continued line, or align after  or   for continued logic operations.
 * Comments are just as important in a shell script as in C code.
 * Use  instead of   for subshell commands, since the former is easier to see the start and end of the subshell command, avoids confusion with   and a small font, and   can be nested.  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.
 * Use "here string" like  instead of   to avoid forking a subshell and pipe
 * Use built-in Bash Parameter Expansion for variable/string manipulation rather than forking sed/tr if possible.
 * Avoid use of " " since " works just as well and avoids a separate fork + pipe
 * If a variable is intended to be used as a boolean, then it must be assigned as followed:
 * for loops it is possible to avoid a subshell for  using the built-in iterator for fixed-length loops (unfortunately,   does not work):
 * 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 " " 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)
 * Function arguments should be given local variable names for clarity like " ", rather than being used as  in the function
 * Use  instead of , since   is RHEL-specific

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