In a bash script, an outer function declares `local retries=3` and then calls a helper function that reads `$retries` — and the helper sees the value 3 even though it never declared or received it. Which scoping rule does bash use to allow this, and how does it differ from the lexical scoping of C, Java or Python?

## Two ways to resolve a name When code mentions `retries`, the language has to decide which binding that means. There are two families of answer: - **Lexical (static) scoping** — the one almost every modern language uses. The binding is decided by the *text* surrounding the reference: enclosing blocks, then enclosing functions, then module/global. Who called the function is irrelevant, and you can determine the answer by reading the source. - **Dynamic scoping** — the binding is decided by the *call stack at runtime*. The most recent still-active declaration of that name wins, no matter which function made it. Bash is dynamically scoped. This is not a quirk of `local`; it is how `local` is defined to work. ## What the runtime actually does There is one variable table for the shell. `local retries=3` does not create a private namespace; it saves whatever `retries` currently holds, installs a new value in the same table, and schedules the old value to be restored when the function returns. While the function is running, that new value simply *is* the shell's `retries` — so anything running during that window sees it, including functions called several levels down. ```bash show() { echo "helper sees: ${retries-unset}"; } outer() { local retries=3; show; } outer # helper sees: 3 show # helper sees: unset ``` The same call to `show` prints different things depending on who called it. That is the definition of dynamic scoping, and it is why you cannot decide what a bash function reads by reading the function alone. ## The two consequences that matter **A callee can clobber a caller's local.** Visibility runs both ways: the helper can also *assign* `retries`, and the assignment lands on the caller's binding, not on a fresh global. The realistic version of this bug uses a boring name: ```bash helper() { for i in 1 2 3; do :; done; } # no local i main() { local i for i in a b c; do helper echo "$i" # still a, b, c? only because for reassigns i each pass done } ``` Any loop or counter in the caller that the callee also touches is a live hazard, and nothing in bash reports it. This is the single strongest argument for declaring *every* function-internal variable, loop counters included, as `local`. **Inherited visibility is not an interface.** A helper that reads `$retries` because some caller happened to define it has an invisible dependency. It works today and fails the first time someone calls it from a different function, or in a unit test, or after a refactor moves the declaration. There is no compile-time signal — you get an empty string, and under `set -u` you get an abort at a line that looks fine. The fix is ordinary discipline: pass the value in as a positional parameter, and make the dependency explicit in the function's own text. ```bash retry_count() { local retries=$1; ...; } outer() { local retries=3; retry_count "$retries"; } ``` ## Where the visibility stops Dynamic scope follows the call stack of *this shell*. A subshell — a forked copy of the shell — starts from a snapshot, so it can read the caller's locals but its own assignments die with it; that isolation is the subject of its own topic. External commands are different again: they are separate programs and receive only the exported environment, so a local variable is invisible to them unless it was exported. One related nuance is `unset` inside a function. Because `unset` operates on the current dynamic binding, unsetting a name a caller declared local can expose an outer binding rather than removing the variable outright. It is a corner most scripts should simply avoid: do not unset names you did not declare. ## How to talk about it A crisp interview answer names the rule (dynamic scoping), states the mechanism (one variable table, save/restore around the call), contrasts it with lexical scoping in one sentence, and then lands on the practical stance: bash gives you the visibility whether you want it or not, so the engineering job is to declare locals everywhere and pass data explicitly, treating any reliance on a caller's variable as a defect waiting for a refactor.