Where does shlex.quote's guarantee stop when building a shell command string?

## What the function actually does `shlex.quote(s)` tests the value against a set of characters that are safe to a POSIX shell unquoted — letters, digits, and a small punctuation set including `@ % + = : , . / -` and underscore. If every character is in that set, the value is returned unchanged. Otherwise it is wrapped in single quotes, and any embedded single quote is rewritten as the close-quote/escaped-quote/reopen-quote sequence, because a POSIX shell offers no escape *inside* single quotes. Single quotes are the strong quoting form: within them, no expansion, splitting or substitution happens at all. That is the entire guarantee — the result is one shell word whose value is exactly `s`. `shlex.join(seq)` is the list-shaped companion: it applies `quote` to every element and joins with spaces, giving you a command string that a shell will re-split into the same list. `shlex.split(s)` is the inverse lexer, tokenising a command string with POSIX quoting rules so you can turn a configured command into an argument list for `subprocess`. `shlex.split` is a parser, not a sanitiser — it tells you how a shell *would* split a string; it never makes an untrusted string safe. ## Limit one: one shell, and it is a POSIX one The `shlex` module models POSIX shell lexing. Its output is not valid quoting for `cmd.exe`, whose quoting and escaping rules are different, whose `%VAR%` expansion happens before the argument is even seen, and whose `&`, `|` and `^` are syntax that single quotes do not neutralise — `cmd.exe` does not treat the single quote as a quoting character at all. There is no standard-library equivalent for that platform, which is a strong argument for never constructing a shell command string on Windows in the first place. ## Limit two: one quoting pass covers one parse Quoting is not a property of the value; it is a property of the value plus the number of times something will parse it. Every layer that re-parses removes one level of quoting. A command sent to a remote shell over a session that itself takes a command string is parsed by your local shell and again by the remote one. `sh -c` nested inside `sh -c` is two parses. So is a command written into a crontab entry, or a value baked into a shell script that another script sources. Quote once per parse: `shlex.quote(shlex.quote(value))` for a two-level case, or restructure so the value travels out of band — through the environment, on standard input, or as a positional parameter to a constant script — and is never part of a parsed string. ## Limit three: quoting sets boundaries, not meaning This is the limit candidates miss. Once quoting has done its job, the value arrives at the target program as exactly one argument, and the program then applies its *own* rules. A filename beginning with `-` or `--` is a flag: `--output=/etc/passwd` passes through `shlex.quote` unchanged because every character in it is in the safe set, and the invoked tool will happily treat it as an option. This is argument injection, and no amount of shell quoting touches it. The defences are the `--` end-of-options separator where the program honours it, prefixing relative paths so they cannot start with a dash, and validating that a value is the kind of thing you meant — a path under a known root, a member of an allow-list — before it goes anywhere near a command line. ## Where quoting sits in the ranking Rank the options honestly. Strongest: no external command at all, because the standard library already does the job. Next: an argument list with `shell=False`, where no parser exists between your values and the child's argv. Next: a shell, but with the command template constant and dynamic values passed as positional parameters so the shell only ever expands `"$1"`. Weakest of the acceptable options: a shell with values interpolated through `shlex.quote`. Below the line: hand-rolled escaping with `str.replace`, which fails on the first character class the author did not think of. `shlex.quote` earns its place as the tool you use when you have already decided a shell is required. Presenting it as the reason `shell=True` is safe inverts the ordering — the strong answer names it as a fallback and says which of the stronger options was ruled out and why.