That's neat, but if your bash script needs a backtrace it should not be a bash script. To each their own though.

Or go the other direction: stop trying to do fancy things and write simpler code that avoids errors.

  #!/bin/sh
  [ "${DEBUG:-0}" = "1" ] && set -x
  set -u
  foo="$( my-external-program | pipe1 | pipe2 | pipe3 )"
  if [ -z "$foo" ] ; then
      echo "Error: I didn't get any output; exiting!"
      exit 1
  fi
  echo "Well I got something back. Was it right?"
  if ! printf "%s\n" "$foo" | grep -q -E 'some-extended-regex' ; then
      echo "Error: '$foo' didn't match what I was looking for; exiting!"
      exit 1
  fi
  echo "Do the thing now..."

Advanced diagnosis code won't make your program work better, but it will make it more complicated. Re-running with tracing enabled works just as well 99% of the time.

I actually tried rewriting this in Python, but gave up since Python's startup latency is atrocious if you have even a few imports (and using a socket to a pre-existing server is fundamentally unable to preserve enough process context related to the terminal). Perl would probably be a better fit but it's $CURRENTYEAR and I've managed to avoid learning Perl every year so far, and I don't want to break my streak just for this.

The Bash code is not only fast but pretty easy to understand (other than perhaps the header, which I never have to change).

>I'd be interested in any bug reports

What's the point? You can't fix them anyway

There are no objects in bash. There are indexed and associative arrays and both can be iterated over like so:

  for value in "${SOMEARRAY[@]}"; do
    echo "${value}"
  done

  for key in "${!SOMEARRAY[@]}"; do
    echo "key: ${key} - value: ${SOMEARRAY["${key}"]}"
  done

  declare -p SOMEARRAY

  declare -a SOMEARRAY=([0]="a" [1]="b" [2]="c" [3]="d" [4]="e" [5]="f")

Let's "dump" all variables that start with "BASH":

  for k in "${!BASH@}"; do
    declare -p "${k}"
  done

  for k in "${!BASH@}"; do
    echo "${k}: ${!k}"
  done

Are you asking me to defend shell script syntax, or are you criticizing this except from a shell script?

The awk and printf are as obscure and unreadable as Perl, but still probably faster than just starting Perl.

Ironically, in terms of portability, it's probably more likely that awk and printf are installed than Python (or Perl). This application doesn't need Python in the (devcontainer) container, and nobody does sysadmin scripts with lua (which can't `export VARNAME` for outer shells) so shell scripting is justified though indeed arcane.

Getopt is hardly more understandable than a few loops through $@ with case statements.

I don't understand the relevance of other tools to "getting decent error reports in Bash"?

There are great logging (and TAP testing) libraries in Python, but that doesn't solve for debugging Bash?

There is at least one debugger for Bash scripts.

Perl had numerous magic, one/two letter variables and copious regexp use, which is what gave it the line noise insult. Wtf is $@ and $_? After spending enough time breathing Perl you got a feel and could actually read it, but take a break and forget all the things, and it's back to being inscrutable. Meanwhile, the bash above isn't totally inscrutable. It's not python clear, and I don't know what SHLVL is without looking it up, but the rest is clear enough (awk with NR, isn't self explanatory, but unfortunately for me I've used too much awk).

Yeah but each only exists once. If you wanna clean up on ERR and also use that trap for debugging you need to implement some janky layer on top of the trap.

(FWIW my take away from issues like this is always: Bash is not a serious programming language. If you are running up against these limitations in real life it's time to switch language. The challenge is really in predicting when this will happen _before_ you write the big script!)

Take care that set -o pipefail will not work on older dash (including IIRC the current Ubuntu LTS), and neither will set -o pipefail || true if set -e is in effect. (For some reason that I’m too lazy to investigate, a failing set invocation will crash the script immediately rather than proceed into the second branch.) The best I could think of to opportunistically enable it was to use a subshell:

  if (set -o pipefail 2>/dev/null); then set -o pipefail; fi

(I rather dislike shellcheck because it combines genuine smells with opinions, such as insisting on $(...) instead of `...`. For the same reason, with Python I regularly use pyflakes but can’t stand flake8. But to each their own.)

That's a pitfall №60

https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail

What about for `/bin/sh`, i.e. posix compliant shells like dash?

Only set -eu is defined in POSIX and supported by dash.

> For what it's worth, I think `set -euo pipefail` should be default for every script, and thoroughly checked with shellcheck.net.

This

Is that a safety point of view? Is shell supposed to be input-safe? I may have limited shell skills but it doesn’t seems like it’s designed to be safe.

Why? It's not like you couldn't get the source of the running script anyway.