🗂️Module 10 — Arrays and Associative Arrays

first:   web-1
count:   4
indexes: 0 1 2 3

What to read out of it: four values, one of them containing a space, counted as exactly 4 — the collection knows its own boundaries, which no space-separated string ever could (that was Module 2's whole tragedy). The ! prefix meaning "give me the indexes, not the values" is a shape worth filing: it returns transformed for associative arrays in Part C, where the indexes are names.

[web-1]
[web-2]
[db primary]
[cache-1]
---
[web-1 web-2 db primary cache-1]
---
[web-1]
[web-2]
[db]
[primary]
[cache-1]

What to read out of it: quoted-@ gave four brackets with db primary whole — the collection survived. Quoted-* gave one bracket — the weld. Unquoted gave FIVE brackets: bash expanded, then word-split, and the space inside db primary became a boundary — a fleet script just gained a host named db and another named primary, neither of which exists. Every array loop you ever write is for h in "${hosts[@]}" — the quoted-@ spelling, untouched, forever.

count: 5
count: 4  indexes: 0 2 3 4
count: 4  indexes: 0 1 2 3

What to read out of it: after the unset, four elements — at indexes 0, 2, 3, 4. The hole is real and permanent until you act. The rebuild line — expand-quoted, re-collect — closes it: same four elements, dense numbering. If you take one habit from this section: "${arr[@]}" iteration never sees holes, so scripts that stick to it are immune to the whole sparse-array bug class.

The direct answer: arr=(a b "c d") creates an indexed array; "${arr[0]}" reads one element; "${arr[@]}" expands all elements one-word-each; "${#arr[@]}" counts; arr+=(e) appends; for x in "${arr[@]}" iterates safely.

Going deeper: say why arrays over space-separated strings — elements keep their boundaries, so values with spaces survive; and the quoting law inherited from $@/$*: quoted-@ forwards, quoted-* welds, unquoted destroys. Note arrays are bash (and ksh/zsh) — not POSIX sh.

The details that separate candidates: the sparse-array behavior of unset (indexes don't renumber; count ≠ highest index; "${arr[@]}" iteration as the immunity); and the brace-trap that $arr alone means element 0 — both are the follow-ups strong interviewers reach for.

The direct answer: values: echo "${array[@]}"; indexes: echo "${!array[@]}".

Going deeper: Edureka's published answer writes both unquoted — which works for their spaceless sample and silently breaks on real data; you can now say precisely why, and that the robust display is printf '[%s]\n' "${array[@]}" (element boundaries made visible). The ! prefix generalizes: on associative arrays it yields the keys, making for k in "${!map[@]}" the universal map-iteration idiom.

The details that separate candidates: pairing values-and-indexes in one loop — for i in "${!arr[@]}"; do echo "$i: ${arr[$i]}"; done — the spelling that survives sparse arrays, where a naive 0..count loop breaks; naming that failure unprompted is the differentiator.

loaded: 3
[web-1]
[web-2]
[db primary]
first two: web-1 web-2

What to read out of it: three lines became three elements — db primary intact, no IFS ceremony required (mapfile splits on newlines only, by design; it is the collection-shaped sibling of while IFS= read -r). The last line is Module 9's slice syntax promoted to collections: ${servers[@]:0:2} — offset and length, but counting elements. Choose by need: streaming loop for transform-as-you-go over big inputs; mapfile for "I need the whole list as a thing."

The direct answer: mapfile -t arr < file — one line per element, -t stripping newlines. From a command: mapfile -t arr < <(command) (process substitution, Module 12's tool, previewed).

Going deeper: name the anti-pattern it replaces — arr=($(cat file)) splits on all whitespace and glob-expands, Module 6's cat-loop disease in array form — and the pre-mapfile portable spelling (a while-read loop appending with arr+=("$line")), worth knowing for old bash. State the streaming-vs-loading trade: mapfile holds everything in memory; while-read streams.

The details that separate candidates: the < <(cmd) spelling and why the obvious cmd | mapfile -t arr fails silently — the pipeline puts mapfile in a subshell and the array evaporates with it (Module 12's headline gotcha, cited by name); knowing that one failure mode is the strongest signal on this question.

db port: 5432
count:   3
db -> 5432
web -> 8080
cache -> 6379
web is mapped
queue is not mapped

What to read out of it: lookups read like sentences — the map's whole point. But stare at the loop's order: db, web, cache — neither insertion order (web, db, cache) nor alphabetical. That is the no-order rule showing itself; your machine may print another permutation, and that variability is the expected result. The last two lines are the existence idiom earning its keep: queue being unmapped is a checkable fact, not a silent empty string.

The direct answer: string-keyed maps, declare -A map; map[key]=value; ${map[key]} — for lookups by name: service→port, env→URL, host→state. Iterate keys with "${!map[@]}"; count with "${#map[@]}".

Going deeper: the two sharp edges — the mandatory declare -A (without it, keys evaluate as arithmetic and silently collapse onto index 0) and no ordering guarantees (sort keys when output must be stable). Requires bash 4+; notably absent on stock macOS bash 3.2 (the Module 1 caveat, resurfacing).

The details that separate candidates: the key-existence idiom ${map[k]+x} and why it beats -n "${map[k]}" (empty value vs absent key are different facts); and the honest design boundary — nested structures don't exist in bash, so a map-of-lists means encoded values or parallel arrays, and "this data has outgrown bash, use jq/python" is a professional answer, not a confession.

The direct answer: because arrays preserve element boundaries. A string hosts="web-1 web-2" cannot hold a value containing a space, cannot be counted reliably, and every use re-splits it; an array holds each value intact, counts itself ("${#hosts[@]}"), and iterates safely ("${hosts[@]}").

Going deeper: the string version is the Module 2 word-splitting hazard institutionalized — it works until the first spacey value, then fails at every use site simultaneously. Arrays move the boundary decision to fill time (mapfile, globs, explicit quoting) and make every later use safe by construction.

The details that separate candidates: naming the one place strings still win — exporting to child processes (arrays don't export; a child needs the data serialized, e.g. newline-joined, and re-parsed — a real bash limitation worth admitting); and the observation that positional parameters are themselves an array, which is why "$@" and "${arr[@]}" obey identical laws.

Diagnosis. Module 6's cat-loop disease, array edition: $( ) substituted the file, unquoted expansion word-split it, and the array collected words, not lines. Three fake hosts from one real line.

Work the steps: printf '[%s]\n' "${targets[@]}" versus wc -l hosts.txt — element count exceeds line count; the brackets show exactly where lines shattered.

Fix and prevention: mapfile -t targets < hosts.txt — line-per-element by construction. Then the boundary guard: validate each element ([[ "$t" =~ ^[a-zA-Z0-9.-]+$ ]] || die "bad hostname: $t") so the next surprising entry fails loudly at load time instead of weirdly at SSH time.

Diagnosis. The missing-declare collapse (C1): without -A, role became an indexed array; web and db were evaluated as arithmetic — unset variable names, both worth 0 — so every write landed on element 0 and the last writer won. (Keys with hyphens like web-1 fail differently: bad array subscript, arithmetic refusing a negative index — loud, and in a way luckier.) It "worked in testing" because testing read back the same key it had just written — the one pattern that can't expose last-write-wins.

Work the steps: declare -p role — the output opens declare -a (indexed) with a single element; that one line is the entire diagnosis.

Fix and prevention: restore declare -A role (top of script, beside the constants — E1's placement rule exists to make such deletions visible in review). Add the cheap tripwire test that testing lacked: write two keys, read both back, compare count to 2.

Diagnosis. C1's no-order rule meeting a workflow that assumes stability: for h in "${!status[@]}" emits whatever order the hash table feels like, per run. Nothing is broken in bash; the interface (a diffable report) has a requirement the data structure never promised.

Work the steps: run the report twice in a row; diff — the shuffle reproduces without any data change.

Fix and prevention: impose order at the boundary: for h in $(printf '%s\n' "${!status[@]}" | sort); do echo "$h: ${status[$h]}"; done — or iterate the source hostlist array (which has stable order) and look each host up in the map. General rule for the runbook: maps are for lookup; any output humans read or diff gets ordered deliberately on the way out.

Diagnosis. The sparse trap (A3) plus index arithmetic: each unset punches a hole; the second loop walks 0..count-1, where count has shrunk but the surviving indexes haven't moved — so it stops before the tail (skipped hosts) and dereferences holes on the way (empty-string pushes). Two symptoms, one cause: index math over a sparse array.

Work the steps: after the removal pass: echo "${!hosts[@]}" — gaps visible; echo "${#hosts[@]}" vs the highest index — mismatch confirmed.

Fix and prevention: either compact after removals (hosts=("${hosts[@]}")) or — structurally better — stop removing mid-structure: build a new array of keepers (for h in "${hosts[@]}"; do keep "$h" && new+=("$h"); done; hosts=("${new[@]}")), and iterate with "${hosts[@]}" so holes can't exist in the first place. Filter-into-new beats delete-in-place in bash every time.