This style is preferred as it makes it possible to use more modern bash
on systems where /bin/bash is ancient. (looking at you, macos)

`set -u` guards against using unassinged vars but most of this code
would break.
We'll address this later on a file by file basis, with tests.

The first test is to apply shellcheck linting to the bash code.

The following commits will address the linting errors found here.

The `[` is just a command with args and expects/ignores the `]` final arg.

That means you need to be very concerned about what's inside `[ ... ]`.

The `[[ ... ]]` is Bash syntax and everything inside is handled as
syntax.
That means you don't need to quotes variable expansions.
Bash knows what you want and does it properly.

Some related changes were made in this context:

* [[ $foo ]] same as [[ -n $foo ]] same as [[ $foo != "" ]]
* [[ -z $foo ]] same as [[ $foo == "" ]]
* Prefer == over = for string equality
* Prefer -eq over == for numeric equality
* $* means all aregs expanded into 1 string
* Words without meta chars are strings in Bash. No need to quote them.

Note: the RHS of a == or != op must be quoted if it is a variable
expansion, but shellcheck would complain if you didn't quote it.

All the files are still shellcheck compliant.

Very confident of this commit.

(in lein and bump)

Added a couple tests but need more rigorous testing to make sure
everything works without error.

In Bash `foo=$bar` or `foo=$( bar $baz )` is smart about parsing and
doesn't blindly expand vars with spaces or meta chars.

Arguments with expansions, on the other hand, need quoting.

Preferred to only use double quotes when expansions are present.

Else use single quotes.

Makes code cleaner and easier to read.
Makes it obvious when things are going to stdout or stderr.

Note: `printf` repeats its pattern until all args are consumed, so the
`msg` function will print a line for each arg.

Unlike vars, functions in bash can contain most of the chars found in
file names, which makes sense as a command can either be a function or a
PATH command.

A Lisper should like it.

Note: you can end a line with && || or | and it will continue without
using \.

command is a bash builtin

Syntax available since bash 3.2

$(dirname "$SCRIPT"$) makes not sense to me.

Surprised it's not a bash syntax error though