Skip to content(if available)orjump to list(if available)

Getting decent error reports in Bash when you're using 'set -e'

Grimeton

You can just do

  trap 'caller 1' ERR
should do the same thing. Also you should set "errtrace" (-E) and possibly "nounset" (-u) and "pipefail".

gkfasdfasdf

or even use caller to print a full backtrace: https://news.ycombinator.com/item?id=44636927

o11c

FWIW, I've grown the following which handles a few more cases. For some reason I wasn't aware of `caller` ...

    set -e

    is-oil()
    {
        test -n "$OIL_VERSION"
    }

    set -E || is-oil

    trap 'echo "$BASH_SOURCE:$LINENO: error: failure during early startup! Details unavailable."' ERR

    magic_exitvalue=$(($(kill -l CONT)+128))

    backtrace()
    {
        {
            local status=$?
            if [ "$status" -eq "$magic_exitvalue" ]
            then
                echo '(omit backtrace)'
                exit "$magic_exitvalue"
            fi
            local max file line func argc argvi i j
            echo
            echo 'Panic! Something failed unexpectedly.' "(status $status)"
            echo 'While executing' "$BASH_COMMAND"
            echo
            echo Backtrace:
            echo
            max=${#BASH_LINENO[@]}
            let max-- # The top-most frame is "special".
            argvi=${BASH_ARGC[0]}
            for ((i=1;i<max;++i))
            do
                file=${BASH_SOURCE[i]}
                line=${BASH_LINENO[i-1]}
                func=${FUNCNAME[i]}
                argc=${BASH_ARGC[i]}
                printf '%s:%d: ... in %q' "$file" "$line" "$func"
                # BASH_ARGV: ... bar foo ...
                # argvi          ^
                # argvi+argc             ^
                for ((j=argc-1; j>=0; --j))
                do
                    printf ' %q' ${BASH_ARGV[argvi+j]}
                done
                let argvi+=argc || true
                printf '\n'
            done

            if true
            then
                file=${BASH_SOURCE[i]}
                line=${BASH_LINENO[i-1]}
                printf '%s:%d: ... at top level\n' "$file" "$line"
            fi
        } >&2
        exit "$magic_exitvalue"
        unreachable
    }
    shopt -s extdebug
    trap 'backtrace' ERR

edoceo

What the hell. This is cool and all but I'm looking at it as a signal I should move up one tier in language (eg: to Perl, PHP, Python or Ruby)

o11c

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).

dataflow

PHP maybe? Or in limited cases, AWK? But I'd definitely learn Perl, it's a gem.

Fire-Dragon-DoL

Maybe try ruby, or you could use go (yeah, have to compile)

chubot

I think you should be able to get rid of the is-oil part, because set -E was implemented last year

    $ osh -c 'set -E; set -o |grep errtrace'
    set -o errtrace
I'd be interested in any bug reports if it doesn't behave the same way

(The Oils runtime supports FUNCNAME BASH_SOURCE and all that, but there is room for a much better introspection API. It actually has a JSON crash report with a shell stack dump, but it probably needs some polish.)

oguz-ismail

>I'd be interested in any bug reports

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

bjackman

But trap doesn't "stack" (like e.g. defer in Go) so if you do this it's not available for other purposes like cleanup

teddyh

Yes. This also means that if you use a third-party shell library which uses “trap” internally (like shunit2), you can’t use “trap” in your own script at all.

gkfasdfasdf

not sure what you mean, you can have separate ERR and EXIT traps that run independently.

newAccount2025

Why don’t all shells just do this?

inetknght

Perhaps you underestimate just how many scripts are poorly written and part of your operating system.

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

mananaysiempre

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
Or you can just target bash, I guess.

(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.)

koolba

> such as insisting on $(...) instead of `...`.

Only one of those can be (sanely) nested. Why would you ever want to use backticks?

imcritic

larkost

I have never liked this statement of the problem.

It is not that `set -e` is bad, it is that bash is a bit weird in this area and you have to know when things eat errors and when they don't. This is not really changed by `set -e`: you already had to know them to make safe code. `set -e` does not wave a magic wand saying you don't have to understand bash error control.

But having `set -e` is almost universally better for people who do not understand it (and I would argue also for people who do). Without it you are responsible for implementing error handling on almost every line.

As other have already said: this is one of those things that generally pushes me to other languages (in my case often Python), as the error handling is much more intuitive, and much less tricky to get right.

eikenberry

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

scns

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

This

koolba

Automatically leaking the line number and command, even to stderr is not a sane default.

null

[deleted]

forrestthewoods

Because shells weren’t supposed to be doing complex logic. People use shells to do way way way more than they should.

westurner

Setting PS4 gets decent error reports with `set -x` (and `set -x -v`; `help set`).

Here's an excerpt that shows how to set PS4 from a main() in a .env shell script for configuring devcontainer userspace:

  for arg in "${@}"; do
  case "$arg" in
  --debug)
      export __VERBOSE=1 ;
      #export PS4='+${LINENO}: ' ;
      #export PS4='+ #${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]:+${FUNCNAME[0]}()}:$(date +%T)\n+ ' ;
      #export PS4='+ ${LINENO} ${FUNCNAME[0]:+${FUNCNAME[0]}()}: ' ;
      #export PS4='+ $(printf "%-4s" ${LINENO}) | '
      export PS4='+ $(printf "%-4s %-24s " ${LINENO} ${FUNCNAME[0]:+${FUNCNAME[0]}} )| '
      #export PS4='+ $(printf "%-4s %-${SHLVL}s %-24s" ${LINENO} "     " ${FUNCNAME[0]:+${FUNCNAME[0]}} )| '
      ;;
  --debug-color|--debug-colors)
      export __VERBOSE=1 ;
      # red=31
      export ANSI_FG_BLACK='\e[30m'
      #export MID_GRAY_256='\e[38;5;244m'    # Example: a medium gray
      export _CRESET='\e[0m'
      export _COLOR="${ANSI_FG_BLACK}"
      printf "${_COLOR}DEBUG: --debug-color: This text is ANSI gray${_CRESET}\n" >&2
      export PS4='+ $(printf "${_COLOR}%-4s %-24s%s |${_CRESET} " ${LINENO} "${FUNCNAME[0]:+${FUNCNAME[0]}}" )'
      ;;
   esac
   done
This, too:

  function error_handler {
    echo "Error occurred on line $(caller)" >&2
    awk 'NR>L-4 && NR<L+4 { printf "%-5d%3s%s\n",NR,(NR==L?">>>":""),$0 }' L=$1 $0 >&2
  }
  if (echo "${SHELL}" | grep "bash"); then
    trap 'error_handler $LINENO' ERR
  fi

kjellsbells

(I'm sure this is lovely Bash, but for all the people who rejected Perl for its modem line noise vibe...what do ya think of this?)

As an aside, I actually wonder if Bash's caller() was inspired by Perl's.

There is also Carp and friends, plus Data::Dumper when you not only need the stack trace but also the state of objects and data structures. Which is something that I don't think Bash can really do at all.

Grimeton

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
or with the help of the keys:

  for key in "${!SOMEARRAY[@]}"; do
    echo "key: ${key} - value: ${SOMEARRAY["${key}"]}"
  done
If you want to dump the data of any variable you can just use declare -p

  declare -p SOMEARRAY
and you get something like this:

  declare -a SOMEARRAY=([0]="a" [1]="b" [2]="c" [3]="d" [4]="e" [5]="f")
What you can do, if you have a set of variables and you want them to be "dumped", is this:

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

  for k in "${!BASH@}"; do
    declare -p "${k}"
  done
Or one could do something like this:

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

But the declare option is much more reliable as you don't have to test for the variable's type.