A bash script dies with `deploy.sh: line 87: ...` inside a helper function that is called from a dozen places, so the line number alone does not tell you which call path got there. Which bash builtin and which shell arrays let a script print its own call stack?

## Bash has a call stack, and it is readable Every function call and every `source` pushes a frame that bash keeps for the life of the call. Three arrays and one builtin expose it, and together they turn a bare line number into a path through the program. ## The arrays They are parallel: index `i` in each describes the same frame. - **`FUNCNAME`** — `FUNCNAME[0]` is the function currently executing, `FUNCNAME[1]` is the function that called it, and so on outward. Outside any function, `FUNCNAME` is empty, which is why prefixes and stack printers write `${FUNCNAME[0]:-main}`. - **`BASH_SOURCE`** — `BASH_SOURCE[i]` is the source file in which `FUNCNAME[i]` is defined. `BASH_SOURCE[0]` inside a function is therefore the library file that defines it, not necessarily the script you invoked. It is also the correct way, in general, for a script to learn its own path — unlike `$0`, it stays right in a sourced file. - **`BASH_LINENO`** — the off-by-one one. `BASH_LINENO[i]` is the line number, in the file `BASH_SOURCE[i+1]`, at which `FUNCNAME[i]` was called. So it describes call *sites*, not the line currently executing; the currently executing line is `$LINENO`. A stack printer falls straight out of that: ```bash stacktrace() { local i for (( i = 1; i < ${#FUNCNAME[@]}; i++ )); do printf ' at %s (%s:%s)\n' \ "${FUNCNAME[i]:-main}" "${BASH_SOURCE[i]}" "${BASH_LINENO[i-1]}" >&2 done } ``` It starts at 1 to skip `stacktrace` itself, and pairs frame `i`'s name with the call-site line recorded at `i-1`. ## The `caller` builtin `caller` reads the same stack. With no argument it prints the line number and source file of the current subroutine call. Given a non-negative integer it prints the line number, subroutine name and source file for that position in the stack, and it returns non-zero when the requested frame does not exist — which gives the idiomatic walk: ```bash print_stack() { local i=0 while caller "$i"; do ((i++)); done } ``` Each line describes where that frame was entered from, innermost first, and the loop terminates naturally when the stack runs out. `caller` is meaningful only inside a function or a sourced file; at the top level of a script there is no subroutine call to report and it returns non-zero. One related builtin behaviour worth knowing: with `shopt -s extdebug` enabled, `declare -F name` prints the function's name together with the line number and file where it was defined, which answers "where is this function actually defined?" in a script that sources several libraries. ## Hooking it up A stack printer is only useful if something calls it on the failure path. The natural places are a diagnostic helper — a `die()` that prints the message, prints the stack, and exits — or a debug hook. Bash's `DEBUG` trap runs before every simple command and makes the command about to run available in `$BASH_COMMAND`, and the `RETURN` trap runs when a function or sourced file returns; by default neither is inherited by shell functions, command substitutions or subshells unless `set -o functrace` (`set -T`) is enabled. Those hooks let you build step-tracing or timing on top of the same stack information. How error *policy* is wired — which failures abort, what an error trap should do, how exit codes are chosen — is a separate discipline from the mechanics of reading the stack, and belongs with the script's error-handling design. ## When it earns its keep For a fifty-line script, a line number is enough. The stack pays for itself when: - Several scripts `source` a shared library and a helper in it fails; the line number points into the library, and only the stack says which caller passed the bad argument. - The failing helper is generic — `require_var`, `retry`, `run` — and used everywhere. - The failure is intermittent in a scheduled job, where you get one chance to capture context and cannot reproduce interactively. ## The honest caveat If you are building a stack-trace framework in shell, note what that signals. Deep call graphs across sourced libraries, with a debugger's worth of introspection bolted on, is usually the point at which the script has outgrown bash and a real language with exceptions, stack traces and tests would be cheaper to operate. The stack tools are for making an existing script diagnosable, not for justifying a larger one.