Since bash expands a command line only once, when does a script genuinely need `eval` to force a second pass, and which bash features let you avoid reaching for it?

## Why a second pass is ever wanted Bash expands a command line once, in a fixed sequence of stages, and the pipeline never restarts. That gives a strong guarantee — text that arrives via a variable or a command's output is data, never syntax. It also creates a small class of problems that a single pass cannot express, because the thing you need to compute *is* the syntax: ```bash n=5 echo {1..$n} # {1..5} -- braces already ran cmd='ls -l "my file"' $cmd # four words: ls, -l, "my, file" ``` In the second line the quotes in the value are ordinary characters by the time they exist; quote removal already happened for this command line, and there is no stage left to interpret them. ## What eval actually does `eval` concatenates its arguments with spaces, expands that string once as part of the normal `eval` command line, and then hands the result back to the shell to be **parsed and executed as a fresh command line** — a second complete trip through parsing and all the expansion stages. Two rounds is why the escaping in `eval` code looks strange: you must reason about what survives round one to become the input to round two. ```bash n=5 eval "for i in {1..$n}; do echo \"\$i\"; done" # prints 1..5 ``` Here `$n` is expanded in round one, producing `for i in {1..5}; ...`, and round two finally gets a literal range. The `\$i` is protected so it survives to round two, where the loop variable actually exists. ## The genuinely legitimate uses **Consuming a tool that emits shell code.** Some programs are designed to print assignments for the calling shell to run, because a child process cannot set its parent's environment: ```bash eval "$(ssh-agent -s)" ``` `ssh-agent -s` prints Bourne-shell assignments (`SSH_AUTH_SOCK=…; export SSH_AUTH_SOCK; …`). Capturing them in a variable would leave them as inert text; `eval` is the documented interface. The same pattern appears wherever a tool prints a shell hook or an environment block. This is not injection-by-accident: the contract of the program is "my stdout is shell code", and the trust boundary is the program you chose to run. **Applying computed quoting.** When a string was produced *by the shell itself* in a re-parseable form — `printf '%q'` output, or `set -- "$@"` style argument reconstruction — `eval` is the matching reader for that writer. `%q` exists precisely so that its output is safe to feed back through a second pass. **Reaching a construct that only exists at parse time.** Redirections whose file descriptor number is computed, or the brace-range case above, cannot be expressed as arguments because they are syntax, not data. ## The alternatives that cover most other cases - **A command as an array.** If the problem is "run a command I assembled", store the words as elements and run `"${cmd[@]}"`. Each element stays one word regardless of spaces, with no parsing round and no quoting puzzle. This replaces the great majority of `eval "$cmd"` in real scripts. - **`printf -v` for a computed variable name.** `printf -v "$name" '%s' "$value"` assigns to the variable whose name is in `$name` without any re-parse. Compare `eval "$name=\$value"`, which is the classic injection example when `$name` is attacker-influenced. - **`declare -n` namerefs** (bash 4.3+) give a by-name alias for reading and writing another variable, and indirect expansion `${!name}` reads one — both without a second pass. - **An arithmetic loop** instead of `eval` on a brace range: `for ((i = 1; i <= n; i++))`. - **Functions instead of generated code.** If you find yourself building a script fragment as a string, a function taking parameters is almost always the same thing without the parse. ## The judgment an interviewer is listening for The wrong answer is "never use `eval`" delivered as a slogan, and the other wrong answer is using it as a general-purpose way to run strings. The right shape is: bash's one-pass model is a feature, `eval` is the deliberate escape hatch from it, and you take the hatch only when the *structure* rather than the *arguments* is computed. When you do, everything interpolated into the string must be something you generated — a literal, a number you validated, or `printf '%q'` output — because inside `eval` the data-is-never-syntax guarantee is gone. The security analysis of that boundary, and the wider family of injection sinks it belongs to (`sh -c`, `ssh`, `find -exec` with a shell), is a topic of its own; what belongs here is knowing *why* `eval` is the only thing in bash that grants a second expansion, and that a computed variable name or a computed command line rarely needs one.