Associative Arrays and Namerefs

## The two kinds of bash array Bash has two array types and they are not interchangeable. An **indexed array** is keyed by non-negative integers and is created implicitly the moment you assign to a subscript of a name that has no other type. An **associative array** — a real hash map keyed by arbitrary strings — exists only if you asked for it explicitly with `declare -A` (or `local -A` inside a function). Associative arrays were added in bash 4.0; there is no implicit path to one. That asymmetry is the whole bug. `counts[apple]=3` is a legal assignment even with no prior declaration, so bash quietly does the only thing it can: it creates an indexed array named `counts`. ## Why the subscript becomes zero For an indexed array, the text between the brackets is evaluated as an **arithmetic expression**, exactly as if it were inside `$(( ))`. In arithmetic context a bare word is treated as a variable name, and a variable that is unset or empty evaluates to `0`. So: ```bash counts[apple]=3 # apple is unset -> counts[0]=3 counts[banana]=5 # banana is unset -> counts[0]=5 echo "${counts[apple]}" # -> ${counts[0]} -> 5 ``` Every key in the script maps onto index 0, so the array ends up holding exactly one element that always shows the value written last. The counter appears to work — it just always reports the most recent write. The failure mode gets worse, not better, when a same-named variable happens to exist. If some earlier line set `apple=7`, then `counts[apple]=3` writes index 7 instead, and the array becomes a sparse indexed array whose contents depend on unrelated variables. Renaming a loop variable elsewhere in the script can silently change where the data lands. ## The correct declaration ```bash declare -A counts # must come BEFORE the first assignment counts[apple]=3 counts[banana]=5 declare -p counts # shows a declare -A line with both keys ``` With `-A` in force, the subscript is no longer arithmetic: it is taken as a literal string, so `counts[apple]` and `counts[banana]` are distinct keys. You can also initialise in one step: `declare -A counts=([apple]=3 [banana]=5)`. Order matters absolutely. Declaring after the fact does not repair anything — bash refuses to change an existing array's type and reports `cannot convert indexed to associative array`. You must `unset counts` first, which of course discards whatever it held. ## Scope, and the function trap `declare` inside a function creates a **function-local** variable, the same as `local`. A helper that does `declare -A cache` builds a map the caller never sees, and the caller's later reads fall back to whatever global of that name exists. If a function must populate a map the rest of the script uses, either declare it at top level, or use `declare -gA cache` (the `-g` global flag, bash 4.2+) inside the function. ## How to notice it in review Three habits catch this reliably: 1. **Declare at the top.** Every map gets a `declare -A` line near the top of the script or immediately inside the function that owns it, next to the other declarations — never implicitly at the first assignment. 2. **Print the type when debugging.** `declare -p name` prints the variable with its attributes: `declare -a` means indexed, `declare -A` means associative. If you expected a map and see `declare -a name=([0]="...")`, you have this bug. 3. **Lint it.** ShellCheck flags associative-array syntax used on a variable it never saw declared with `-A`, which is usually the first hint in a large script. ## Why interviewers like it It is the archetype of the tree's favourite shape: code that reads correctly, runs without error, and produces wrong data. There is no exception, no non-zero exit status, and no strict-mode flag that fires — the array is valid, the arithmetic is valid, and only the programmer's intent was lost. Being able to explain *why* the subscript turned into zero (arithmetic evaluation of an unset name) rather than just reciting "you need declare -A" is what separates a memorised answer from an understood one.