A bash script sets `n=5` and then runs `for i in {1..$n}; do echo $i; done`. What does that loop actually print, and why?

## What actually happens Bash expands a command line in fixed stages, and brace expansion is the very first one. When the shell reaches this line: ```bash n=5 for i in {1..$n}; do echo "$i"; done ``` the text it hands to brace expansion is literally `{1..$n}`. A sequence expression is only valid when both endpoints are integer literals (or single characters). `$n` is neither — at this instant it is three characters, `$`, `n`, and nothing has looked at variables yet. So the expansion does not apply, and bash follows its rule for an invalid brace construct: leave it exactly as written, no error, no warning. The next stage, parameter expansion, then does its job and replaces `$n` with `5`. The word is now `{1..5}` — but that is *output* of a completed stage, and bash does not go back and redo an earlier stage on it. Brace expansion has already happened for this command line and will not happen again. The `for` therefore has exactly one word in its list, and prints: ``` {1..5} ``` One iteration, with `i` set to the literal five-character string `{1..5}`. Nothing errors, which is what makes this bug survive code review — a loop that should have run five times ran once, and the body probably did something silly with a filename containing braces. ## The general rule this teaches Anything that happens *before* parameter expansion cannot see a variable's value. Brace expansion is the headline case, but the same order explains tilde expansion: ```bash user=alice echo ~$user # prints ~alice, not /home/alice ``` Tilde expansion also runs before parameter expansion. It looks at the characters after the tilde, sees the literal `$user`, finds no such login name, and leaves the tilde in place; the variable is expanded afterwards. The correct forms are `~alice` written literally, or `eval echo ~"$user"`, or simply reading the home directory from a source that is itself a parameter expansion, such as `$HOME` for the current user. The symmetric point is also worth internalising: anything that happens *after* parameter expansion does apply to the substituted text. Command substitution's output, and a variable's value, are still subject to the later stages of the same pass. So the direction of the asymmetry is precise — later stages see earlier results, earlier stages never see later ones. ## The fixes, in preference order **C-style loop.** The arithmetic `for` evaluates its expressions when the loop runs, long after any expansion decision, so the variable is simply read as a number: ```bash for ((i = 1; i <= n; i++)); do echo "$i" done ``` Note that inside `(( ))` you write `n`, not `$n` — the arithmetic context reads the variable itself. This is a bashism, not POSIX, but it forks nothing and handles an `n` of zero correctly by running the body zero times. **Command substitution over `seq`.** Command substitution happens after brace expansion, so the endpoints are already resolved: ```bash for i in $(seq 1 "$n"); do echo "$i"; done ``` This relies on the unquoted result being split into words, and it forks an external process. `seq` is not POSIX, though it is present on both GNU and BSD systems. **`eval`, deliberately.** `eval "for i in {1..$n}; do echo \"\$i\"; done"` does work: the string is expanded once by the outer command, producing `for i in {1..5}`, and then re-parsed from scratch, so brace expansion gets a second chance with a literal endpoint. It is the honest answer to "how do I force a second pass", but it is the wrong tool here because a plain arithmetic loop does the same job with no re-parsing at all — and putting anything you did not compute yourself inside `eval` is how shell injection happens. **A pre-built array.** If the values come from data rather than a range, collect them into an array and iterate `"${arr[@]}"`; no expansion-order trick is needed at all. ## What interviewers are checking The question is a proxy for whether you have internalised the expansion pipeline or merely memorised syntax. A candidate who says "braces don't work with variables" has memorised the symptom; a candidate who says "brace expansion is the first stage, so it cannot see a value that parameter expansion has not produced yet, and results are not re-scanned" can derive the tilde case, the `{1..n}` case, and the reason `eval` is the only way to get a second pass — all from one rule.