Add shunit2

.gitignore

@@ -1 +1 @@
-shunit2/
+#shunit2/

shunit2/.editorconfig

@@ -0,0 +1,14 @@
+# EditorConfig for shUnit2.
+# https://EditorConfig.org
+
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.sh]
+indent_style = space
+indent_size = 2

shunit2/.githooks/generic

@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# A generic git hook proxy.
+# https://git-scm.com/docs/githooks
+
+run() {
+  hook=$1
+  file=$2
+
+  n=$(echo "${file}" |sed "s/^.*${hook}\.//")
+  echo "running ${n} ${hook}"
+  ${file}
+}
+
+die() {
+  hook=$1
+  echo "${hook} hook did not succeed" >&2
+  exit 1
+}
+
+# Redirect output to stderr.
+exec 1>&2
+
+githooks='.githooks'
+basename=$(basename "$0")
+
+for f in $(cd ${githooks} && echo *); do
+  case "${f}" in
+    ${basename}.*)
+      run ${basename} "${githooks}/${f}" || die "${f}"
+      ;;
+  esac
+done

shunit2/.githooks/pre-commit.shellcheck

@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# Git hook to run ShellCheck.
+#
+# ShellCheck <https://www.shellcheck.net/>
+
+# Treat unset variables as an error when performing parameter expansion.
+set -u
+
+TRUE=0
+FALSE=1
+
+die() {
+  echo "$@" >&2
+  exit 1
+}
+
+if ! command -v shellcheck >/dev/null; then
+  echo 'unable to locate shellcheck' >&2
+  return 0
+fi
+
+success=${TRUE}
+for f in $(git diff --cached --name-only); do
+  # Check for file deletion.
+  if [ ! -r "${f}" ]; then
+    continue
+  fi
+
+  cmd=':'
+  case "${f}" in
+    shflags|shflags_test_helpers) cmd="shellcheck -s sh ${f}" ;;
+    *.sh) cmd="shellcheck ${f}" ;;
+  esac
+  if ! ${cmd}; then
+    success=${FALSE}
+    echo "shellcheck error for '${f}'" >&2
+  fi
+done
+
+exit ${success}

shunit2/.gitignore

@@ -0,0 +1,3 @@
+# Hidden files generated by macOS.
+.DS_Store
+._*

shunit2/.shellcheckrc

@@ -0,0 +1,9 @@
+# ShellCheck (https://www.shellcheck.net/)
+#
+# This file is supported as of shellcheck v0.7.0.
+#
+# TODO(kward): Remove equivalent references in `*_test.sh` from file once
+#   Travis CI upgrades its shellcheck version.
+
+# Disable source following.
+disable=SC1090,SC1091

shunit2/.travis.yml

@@ -0,0 +1,49 @@
+language: bash
+
+env:
+  - SHUNIT_COLOR='always'
+
+script:
+  # Execute the unit tests.
+  - ./test_runner
+
+addons:
+  apt:
+    packages:
+      - ksh
+      - mksh
+      - zsh
+
+matrix:
+  include:
+    ### Ubuntu (https://en.wikipedia.org/wiki/Ubuntu).
+    - os: linux
+      # Support Ubuntu Focal 20.04 through at least Apr 2025.
+      dist: focal
+    - os: linux
+      # Support Ubuntu Bionic 18.04 through at least Apr 2023.
+      dist: bionic
+    - os: linux
+      # Support Ubuntu Xenial 16.04 through at least Apr 2021.
+      dist: xenial
+    - os: linux
+      # Support Ubuntu Trusty 14.04 through at least Apr 2019.
+      dist: trusty
+
+    ### Other OSes.
+    # [2021-10-22 kward] Disable FreeBSD builds until they actually work.
+    #- os: freebsd
+    - os: osx
+
+    ### Run the source through ShellCheck (http://www.shellcheck.net).
+    - os: linux
+      script:
+        - shellcheck shunit2 *_test.sh
+        - shellcheck -s sh shunit2_test_helpers
+
+branches:
+  only:
+  - master
+  - 2.1.x
+  # Tags, e.g. v.2.1.8.
+  - /^v\d+\.\d+(\.\d+)?(-\S*)?$/

shunit2/CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at kate.ward@forestent.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

shunit2/CONTRIBUTING.md

@@ -0,0 +1,147 @@
+Coding Standards
+================
+
+shFlags is more than just a simple 20 line shell script. It is a pretty
+significant library of shell code that at first glance is not that easy to
+understand. To improve code readability and usability, some guidelines have been
+set down to make the code more understandable for anyone who wants to read or
+modify it.
+
+Function declaration
+--------------------
+
+Declare functions using the following form:
+
+```sh
+doSomething() {
+  echo 'done!'
+}
+```
+
+One-line functions are allowed if they can fit within the 80 char line limit.
+
+```sh
+doSomething() { echo 'done!'; }
+```
+
+Function documentation
+----------------------
+
+Each function should be preceded by a header that provides the following:
+
+1. A one-sentence summary of what the function does.
+
+1. (optional) A longer description of what the function does, and perhaps some
+   special information that helps convey its usage better.
+
+1. Args: a one-line summary of each argument of the form:
+
+   `name: type: description`
+
+1. Output: a one-line summary of the output provided. Only output to STDOUT
+   must be documented, unless the output to STDERR is of significance (i.e. not
+   just an error message). The output should be of the form:
+
+   `type: description`
+
+1. Returns: a one-line summary of the value returned. Returns in shell are
+   always integers, but if the output is a true/false for success (i.e. a
+   boolean), it should be noted. The output should be of the form:
+
+   `type: description`
+
+Here is a sample header:
+
+```
+# Return valid getopt options using currently defined list of long options.
+#
+# This function builds a proper getopt option string for short (and long)
+# options, using the current list of long options for reference.
+#
+# Args:
+#   _flags_optStr: integer: option string type (__FLAGS_OPTSTR_*)
+# Output:
+#   string: generated option string for getopt
+# Returns:
+#   boolean: success of operation (always returns True)
+```
+
+Variable and function names
+---------------------------
+
+All shFlags specific constants, variables, and functions will be prefixed
+appropriately with 'flags'. This is to distinguish usage in the shFlags code
+from users own scripts so that the shell name space remains predictable to
+users. The exceptions here are the standard `assertEquals`, etc. functions.
+
+All non built-in constants and variables will be surrounded with squiggle
+brackets, e.g. `${flags_someVariable}` to improve code readability.
+
+Due to some shells not supporting local variables in functions, care in the
+naming and use of variables, both public and private, is very important.
+Accidental overriding of the variables can occur easily if care is not taken as
+all variables are technically global variables in some shells.
+
+Type | Sample
+---- | ------
+global public constant           | `FLAGS_TRUE`
+global private constant          | `__FLAGS_SHELL_FLAGS`
+global public variable           | `flags_variable`
+global private variable          | `__flags_variable`
+global macro                     | `_FLAGS_SOME_MACRO_`
+public function                  | `flags_function`
+public function, local variable  | ``flags_variable_`
+private function                 | `_flags_function`
+private function, local variable | `_flags_variable_`
+
+Where it makes sense to improve readability, variables can have the first
+letter of the second and later words capitalized. For example, the local
+variable name for the help string length is `flags_helpStrLen_`.
+
+There are three special-case global public variables used. They are used due to
+overcome the limitations of shell scoping or to prevent forking. The three
+variables are:
+
+- `flags_error`
+- `flags_output`
+- `flags_return`
+
+Local variable cleanup
+----------------------
+
+As many shells do not support local variables, no support for cleanup of
+variables is present either. As such, all variables local to a function must be
+cleared up with the `unset` built-in command at the end of each function.
+
+Indentation
+-----------
+
+Code block indentation is two (2) spaces, and tabs may not be used.
+
+```sh
+if [ -z 'some string' ]; then
+  someFunction
+fi
+```
+
+Lines of code should be no longer than 80 characters unless absolutely
+necessary. When lines are wrapped using the backslash character '\', subsequent
+lines should be indented with four (4) spaces so as to differentiate from the
+standard spacing of two characters, and tabs may not be used.
+
+```sh
+for x in some set of very long set of arguments that make for a very long \
+    that extends much too long for one line
+do
+  echo ${x}
+done
+```
+
+When a conditional expression is written using the built-in [ command, and that
+line must be wrapped, place the control || or && operators on the same line as
+the expression where possible, with the list to be executed on its own line.
+
+```sh
+[ -n 'some really long expression' -a -n 'some other long expr' ] && \
+    echo 'that was actually true!'
+```