Enhanced log setup capability

[mbland]

Per @JohnOmernik, it would be nice to provide the user with a more comprehensive configuration API. We should knock some ideas around, but as a first draft, I'm thinking of a sourced bash file (logging.conf per John's suggestion) something like:

_GO_LOG_DATEFMT='%Y-%m-%d %H:%M:%S'
_GO_LOG_OPTIONS_INFO=(
  "fmt:default /dev/stdout"
  "date:true /var/log/app/info.log"
  "/var/log/app/info.json"
)
_GO_LOG_OPTIONS_FATAL=(
  "fmt:\e[1m\e[32m /dev/stderr"
  "fmt:same /var/log/app/fatal.log"
  "/var/log/app/fatal.json"
)
_GO_LOG_OPTIONS_CUSTOM=(
  "fmt:json /var/log/app/custom.log"
)

And so forth. I'm gravitating towards Bash vs. JSON or other formats because it minimizes the need for external tooling and I have an idea of how to implement this. For example:

• The option:value parameters are first because they won't contain spaces; I can split the string, loop over the values to parse the options, then join the remaining strings back into a file path (to handle paths with spaces).
• Options like fmt:same will inherit the format of the preceding entry.
• File names ending in .json will automatically get converted to JSON format, but other file names can specify fmt:json as well.
• One timestamp format to rule them all. If it's defined, all log messages will receive them, unless date:false is specified.
• JSON format always gets a timestamp.
• Builtin levels will remain as they are unless overridden by a _GO_LOG_OPTIONS_* setting.

This is completely up for discussion. I'm open to being convinced to use things like YAML and JSON, too, but tend to favor Bash-only solutions to minimize dependencies.

[mbland]

v1.3.0

[JohnOmernik]

So I am perfectly good with Bash vs. JSON. I like the ability to import it easily and without other tools needing to be installed. Thus, output to JSON is ok to require jq (otherwise it won't work) that's an "additional" feature, but for a config file, core processing should be only stock bash. Thus, BASH it is.

[JohnOmernik]

I also think we should step up from a "logging.conf" and instead create a "go.conf" that has various variables that the implemented go-script-bash is working off of. There may be other things that we want to set, other than logging, and should be configurable. Also, setting the location of the conf file in the initial go script seems reasonable... right? Basically, if the variable isn't set there than default to a conf file within the go-script-bash repo that has reasonable defaults....

[mbland]

What do you think about that vs. putting all the config vars in the ./go script itself? Though I do see the appeal of having a separate config file.

If we go the separate config file route, I can see adding a @go.source_config that would default to something like:

@go.source_config() {
  local config_file="${1:-${_GO_SCRIPT}.conf}"
  if [[ -f "$config_file" ]]; then
    . "$config_file"
  else
    echo "Config file $config_file not found." >&2
    exit 1
  fi
}

So in the case of JohnOmernik/zetago, the default config file would be zeta.conf.