Send log messages to multiple output files

[mbland]

Per @JohnOmernik, it may prove convenient to print log messages both the console and a file.

A proof-of-concept of the approach is already implemented in the file module as @go.fds_printf. That function won't be directly applicable; the console will need to include format codes, and the file output should have them stripped by default. Also per #35, it may be desirable to convert the output to JSON for some output files.

[mbland]

v1.3.0

[JohnOmernik]

With the logging to stdout, does it make sense to just treat it as an output, and set the logging level based on the logging configuration, or since it may be very interactive, could add a "CONSOLE_FILTER" level to conf make sense, so people could easily just override it if they were troubleshooting... Let's say the standard CONSOLE_FILTER was set to WARN, but I was having trouble, I could run a command like "CONSOLE_FILTER=DEBUG ./go runmycommand" to get enhanced output without changing a configuration...

This would not apply to the other variable outputs of log files... just console... You'd have the file descriptor output to console, then a CONSOLE_FILTER set in conf, and then the ENV variable, with each level taking precedence (logging set < CONSOLE_FILE in go.conf file < CONSOLE_FILTER set at run time in ENV....)

Just spitballing ideas here...

[mbland]

Ah, I think I see what you mean. I dig it. But I think it's orthogonal to the multi-file descriptor output concept.

What I mean by that is, if there's an INFO log file, and _GO_LOG_CONSOLE_FILTER (keeping with the public env var naming convention) is set to WARN, there'd be a check to see if each file descriptor is a terminal ([[ -t $fd ]]). If so, the INFO message isn't printed. If not, it is.

Of course, now I'm wondering if there should be a _GO_LOG_LEVEL_FILTER that controls output globally, in case users want a single log file, but for error level WARN and up, say.

Implementation-wise, something like:

declare _GO_LOG_CONSOLE_FILTER="${_GO_LOG_CONSOLE_FILTER:-WARN}"
declare _GO_LOG_LEVEL_FILTER="${_GO_LOG_LEVEL_FILTER:-INFO}"
declare __GO_LOG_CONSOLE_PRIORITY
declare __GO_LOG_LEVEL_PRIORITY
...

@go.log() {
  ...
  local level_fds=()
  local level_fd
  local priority
  local log_msg
  ...
  local origIFS="$IFS"
  local IFS=','
  level_fds="${__GO_LOG_LEVELS_FILE_DESCRIPTORS[$__go_log_level_index]}"
  IFS="$origIFS"

  for level_fd in "${level_fds[@]}"; do
    if [[ ! -t "$level_fd" && -z "$_GO_LOG_FORMATTING" ]]; then
      ...
    fi

    log_msg="$(@go.timestamp) $formatted_log_level ${args[*]}$close_code\n"
    # Remove leading spaces if the timestamp is empty
    log_msg="${log_msg## }"

    if [[ -t "$level_fd" ]]; then
      if [[ "$__go_log_level_index" -ge "$__GO_LOG_CONSOLE_PRIORITY" ]]; then
        printf "$log_msg" >&"$level_fd"
      fi
    elif [[ "$__go_log_level_index" -ge "$__GO_LOG_LEVEL_PRIORITY" ]]; then
      printf "$log_msg" >&"$level_fd"
    fi
  done
}

...

_@go.log_init() {
  if [[ -z "$__GO_LOG_INIT" ]]; then
    _@go.log_format_level_labels
    # ...set __GO_LOG_{CONSOLE,LEVEL}_PRIORITY here...
    readonly __GO_LOG_INIT='done'
  fi
}

The above also implies that the priority is determined by the order of levels in _GO_LOG_LEVELS. That will have to be documented, and in the future, there may be a way to inject a new level to precede an existing level, but that'd be for a future release.