Sometimes you genuinely must interpolate a value into a command line that a shell will parse. Explain why quoting and escaping is a structurally weaker defence here, and what exactly you have to model to get it right.

## Why this rung is weaker, stated precisely Structural separation removes the interpreter from the path. Escaping keeps the interpreter and instead transforms the data so that the interpreter will not read it as syntax. That transformation is a **model of the interpreter's grammar**, written by you, and it is correct only to the extent that the model matches the interpreter that actually runs. Three things can invalidate it: you were wrong about the grammar, you were wrong about *which* interpreter runs, or the string gets parsed more than once. All three happen routinely. This is the same reason manual escaping is discouraged at every other injection sink; what is specific here is how many independent grammars are in play. ## Axis one: quoting contexts differ, including in what they cannot express In a POSIX-family shell, single quotes are absolute — every character between them is literal — with one crucial exception: a single quote itself cannot appear inside single quotes, at all, by any escape. The standard technique is to end the quoted run, emit an escaped quote outside it, and start a new run. Any hand-rolled "wrap it in single quotes" helper that does not handle this is broken by exactly one character. Double quotes are not absolute: parameter expansion, command substitution, arithmetic expansion and backslash escapes all still occur inside them. So a value containing `$(...)` inside double quotes still executes a command. Some shells add further quoting forms with their own rules for escape sequences inside them. ## Axis two: escape characters and multi-pass parsing The Windows command interpreter is a different language, not a dialect. Its escape character is different, and it expands environment-variable references *while parsing the line*, before your escaping had any effect on the resulting text — with a delayed-expansion mode that substitutes at execution time and re-parses the result, so a value can be introduced into the line after every check you performed. Then the target program receives the raw command line and splits it into arguments with its own convention. Net effect: one string is lexed by two grammars in sequence, and an escape that satisfies the first can be undone or re-interpreted by the second. Other interpreters add their own passes. A command shell built around an object pipeline tokenizes with its own rules and then *re-serialises* arguments into a native command line when calling an external program, so a value that was safely quoted in that shell's own syntax can be re-split on the way out. ## Axis three: what happens after substitution In POSIX shells, expansion is not the last step. After a variable is substituted, the result undergoes **word splitting** on the characters in the field-separator variable and then **pathname expansion**. This is why an unquoted expansion is unsafe even when the value contains nothing that looks dangerous: a space turns one argument into two, an asterisk turns it into a directory query, and an attacker who can influence the field-separator variable changes what counts as a boundary. Correct quoting has to survive this stage, which is precisely the stage people forget because it happens *after* the text they were looking at. ## Which shell is "the shell"? Escaping correctly requires knowing the interpreter, and often you do not. The system shell may be a small POSIX shell or a large feature-rich one, and they differ in extensions. A remote-execution path runs the *account's login shell*, which the account owner may have changed. A build tool may use a configurable shell. A container image may not contain the shell you assumed. If your escape is tuned to one grammar and a different one runs, the transformation is simply wrong. ## How to do it when you must When the shell genuinely cannot be removed — an existing script you are calling, a scheduled entry, a remote command — apply these in order: 1. **Pin the interpreter.** Invoke a specific shell binary explicitly rather than "whatever the default is," so your model has a fixed target. 2. **Use that shell's own quoting routine**, from a maintained library, rather than a hand-written wrapper. This is the one place where reusing someone else's carefully-tested lexer model is strictly better than writing your own. 3. **Minimise the escaped region.** Get the untrusted value out of the parsed text entirely wherever possible: pass it in the child's environment (the environment is an array of strings, not a parsed line), or write it to a file and pass the path, or feed it on standard input. A value that never appears in the command line does not need quoting. 4. **Prefer closed-world enumeration for anything structural.** If the user chooses *which* command, *which* flag, or *which* target, do not interpolate their string — map a public token to a code-owned invocation. A pattern that constrains characters is open-world and still admits every legitimate-looking flag you did not think about; a finite map is closed-world and owned by your code. This is why enumeration takes the top rung whenever structure itself must vary. 5. **Assume the parse happens again.** Ask what the callee does with the argument: does it re-invoke a shell, expand its own configuration, or interpret the value as an option? Escaping the outer grammar does nothing about the inner one. ## The honest summary for an interview Escaping is a legitimate rung — it is not "never do this" — but it is a *heuristic that depends on a model*, whereas an argument-vector launch is a guarantee that depends on nothing. Say that explicitly, name at least two grammars that diverge, and mention that word splitting and pathname expansion occur after substitution. That answer distinguishes someone who has debugged this from someone who has read a checklist.