A bash wrapper script forwards its arguments with `mytool $@`, and a user who passes an argument containing a space finds that mytool sees two arguments. What do `"$@"`, `$@`, `"$*"` and `$*` each expand to, and which belongs in that wrapper?

## The four forms Bash has two special parameters that stand for "all of the positional parameters", and each has a quoted and an unquoted form. They are not four ways to spell the same thing; they produce four different argument lists. Assume a script has been called with two arguments, `one two` (a single argument containing a space) and `three`: ```bash show() { printf '[%s]' "$@"; echo; } set -- 'one two' three show "$@" # [one two][three] 2 arguments show $@ # [one][two][three] 3 arguments show "$*" # [one two three] 1 argument show $* # [one][two][three] 3 arguments ``` **`"$@"`** is special-cased by the shell: it expands to one word per positional parameter, and each word is taken verbatim — spaces, newlines, tabs, glob characters and all. This is the only form that round-trips an argument list. **`$@` unquoted** first expands to the parameters and then, because the expansion was unquoted, each resulting word goes through word splitting on `IFS` and pathname expansion. An argument containing a space becomes two words; an argument that is literally `*` becomes a list of filenames. That is exactly the failure in the question. **`"$*"`** joins all the parameters into a *single* word, using the first character of `IFS` as the separator. With the default `IFS` that is a space. If you change `IFS`, the join character changes with it: ```bash set -- one two three ( IFS=,; echo "$*" ) # one,two,three ``` That makes `"$*"` genuinely useful for building a human-readable string — a log line, an error message, a comma-separated list — and useless for passing arguments on. **`$*` unquoted** joins on `IFS` and then splits the result back apart on `IFS`, which in practice gives the same word list as unquoted `$@`. There is essentially no reason to write it. ## The empty case The difference nobody remembers until it bites shows up with zero arguments: ```bash set -- # no positional parameters count() { echo "$#"; } count "$@" # 0 count "$*" # 1 - one argument, the empty string ``` So `ssh host "$*"` on a script called with no arguments runs a command with a stray empty argument, while `"$@"` correctly disappears. This is also why `"$@"` is safe as the whole of a command's argument list, and why `set -- "$@"` is a no-op you can rely on. ## Why the wrapper is broken ```bash #!/usr/bin/env bash # broken exec mytool $@ # correct exec mytool "$@" ``` The broken form fails for any argument containing whitespace, for an empty-string argument (which vanishes entirely, shifting every later argument left by one), and for an argument containing a glob character in a directory where it happens to match. All three are user-supplied values, so the bug appears in production and not in your testing. The same rule applies to any place a script re-passes its arguments: `sudo "$@"`, `command "$@"`, `"$@" </dev/null`, and calling a shell function with `myfunc "$@"` — inside a function, `$@` refers to the function's own parameters, not the script's, which is what makes helper wrappers compose. ## Prefixing and suffixing A common need is "my fixed flags, then the user's arguments". You cannot glue text onto `"$@"` as a whole; the concatenation applies only to the first and last words: ```bash set -- a b c printf '[%s]' "pre-$@" # [pre-a][b][c] - rarely what you want mytool --verbose "$@" # the normal, correct shape ``` For anything more structured than "flags then arguments", build the command as an array and expand that — but the quoting rule is identical: the expansion must be quoted or the boundaries are lost. ## What to say in an interview State the rule first — `"$@"` is the only faithful forwarding form — then demonstrate that you know *why*: the quotes suppress the re-splitting and globbing that the unquoted forms undergo, `"$*"` is a join rather than a list, and the zero-argument behaviour differs between the two quoted forms. ShellCheck reports the unquoted forms as `SC2068`.