Bash functions may call themselves. What limits how deep a recursive bash function can go, what does bash's FUNCNEST variable do, and how can such a function tell how deep it currently is?

## Recursion works, with a caveat about state Nothing stops a bash function from calling itself, and the scoping rules make it usable: `local` is per invocation, so each level of a recursive call gets its own copy of the name, saved on entry and restored on return. ```bash countdown() { local n=$1 echo "n=$n" if [ "$n" -gt 0 ]; then countdown "$((n - 1))" fi } ``` Drop the `local` and every level shares one `n`, so the innermost call's assignment is what the unwinding outer calls see — a classic way to turn a correct-looking recursion into an infinite one. That direct connection between per-invocation locals and workable recursion is why the two subjects belong together. ## There is no default depth limit Compare with other languages: CPython raises `RecursionError` at a configurable limit; the JVM throws `StackOverflowError`. Bash, by default, does neither. Frames and saved local values are heap allocations in the shell process, and they simply keep accumulating. A recursion that never reaches its base case ends with the shell consuming gigabytes, then being killed — the process disappears, often with a signal rather than an exit code, and in a container that can mean the OOM killer takes something else with it. That is the practical risk: the failure mode of a buggy recursive bash function is a dead host or a dead pod, not a stack trace. ## FUNCNEST `FUNCNEST` is the guard rail. If it is set to a numeric value greater than zero, it defines the maximum function-nesting level; a call that would exceed it is aborted and bash reports that the maximum function nesting level was exceeded. Setting it to an empty value, zero, or a non-numeric string removes the limit. ```bash FUNCNEST=50 runaway() { runaway; } runaway # aborts at depth 50 instead of eating memory ``` Two caveats worth stating in an interview. First, it is a *bash 4* feature — the bash 3.2 that ships as `/bin/bash` on macOS does not have it, so a script that relies on it for safety is not portable to that interpreter. Second, it counts function nesting, not general recursion: a script that recurses by re-executing itself as a new process is unaffected. ## Knowing your own depth: FUNCNAME `FUNCNAME` is a bash array variable holding the names of the shell functions currently on the execution call stack. `${FUNCNAME[0]}` is the function executing right now, `${FUNCNAME[1]}` is its caller, and so on; when a script (rather than an interactive shell) is running, the bottom-most element is `main`. It only exists while a function is executing. ```bash walk() { local depth=$(( ${#FUNCNAME[@]} - 1 )) # subtract the "main" frame echo "depth=$depth in ${FUNCNAME[0]} called by ${FUNCNAME[1]}" } ``` That makes `FUNCNAME` useful for two things beyond recursion: enforcing your own depth cap portably (compare `${#FUNCNAME[@]}` against a constant and `return 1`), and writing log lines that name the calling function, which is far more informative than a bare message. ## Judgment: should this be recursive at all? Bash function calls are relatively expensive, and every level of recursion allocates saved locals. Directory walking, the most common temptation, is better served by `find` or by `shopt -s globstar` with a `**` glob than by a hand-rolled recursive descent. Parsing nested data — JSON, YAML — is a signal to reach for a tool built for it rather than to recurse in shell. When you do write a recursive function, the checklist is short: declare every working variable `local`; make the base case the *first* thing in the body so it cannot be skipped; cap depth explicitly, either with `FUNCNEST` when you control the interpreter or with a `${#FUNCNAME[@]}` check when you do not; and pass state as arguments rather than relying on the caller's variables being visible.