In a bash wrapper function that passes its arguments on to another command, what is the difference between forwarding them as "$@", as "$*", and as unquoted $@?

## Three expansions that look interchangeable and are not A wrapper function is one of the most common shapes in shell scripting: add a default flag, add retries, add logging, then hand the arguments to the real command. ```bash run() { logger "running: $*"; command curl --fail "$@"; } ``` That one line uses both forms deliberately, and the difference between them is the single most-asked thing about bash functions. ## "$@" — one word per argument Inside double quotes, `$@` is special-cased by the shell: it expands to *n* separate words for *n* arguments, and each word is exactly the argument as received. Spaces, tabs, newlines, glob characters and empty strings all survive, because each expanded word is treated as if it had been individually quoted. This is the whole reason `"$@"` exists — no other expansion in the language does it. ```bash show() { printf '[%s]' "$@"; echo; } fwd() { show "$@"; } fwd "a b" "" c # prints [a b][][c] ``` The forwarded call is byte-for-byte the argument vector the wrapper was handed. ## "$*" — one word, joined by IFS `"$*"` produces a single word: the arguments concatenated, with the first character of the `IFS` variable between them (a space in a default shell). So `show "$*"` above prints `[a b c]` — one argument, and the empty argument has silently collapsed into a doubled separator. Any command receiving `"$*"` sees one long string, which is why `ssh host "$*"` and `docker run img "$*"` behave so differently from their `"$@"` counterparts: the remote or the container gets one argument that it must then re-parse. `"$*"` is not a mistake in itself; it is the right tool when you genuinely want a joined string: ```bash log() { printf '%s %s\n' "$(date +%FT%T)" "$*" >&2; } log deploy finished in 3s # one tidy message ``` Because the join character comes from `IFS`, you can pick it deliberately: `IFS=, ; joined="$*"` builds a comma-separated list. Do that in a subshell or restore `IFS` afterwards. ## Unquoted $@ and $* — the bug Without quotes, both first expand to the arguments separated by spaces and then the *result* goes through word splitting and pathname expansion, exactly like any other unquoted expansion. An argument `report 2024.txt` arrives as two arguments; an argument `*.log` may be replaced by the log files in the current directory; an empty argument vanishes entirely. This is the defect ShellCheck reports as SC2086, and in a wrapper it is especially nasty because the wrapper usually works during testing — the failure appears the first time a user passes a filename with a space. ## The empty-argument-list special case With zero arguments, `"$@"` expands to *nothing at all* — the word disappears, and `cmd "$@"` runs `cmd` with no arguments. `"$*"` under the same conditions expands to one empty word, so `cmd "$*"` runs `cmd` with a single empty argument. For commands that treat an empty argument as a path or a pattern, that difference is the difference between working and failing. ```bash count() { printf '%d\n' "$#"; } both() { count "$@"; count "$*"; } both # prints 0 then 1 ``` ## Forwarding a subset A dispatcher usually consumes the first argument and forwards the rest: ```bash dispatch() { local sub=$1; shift "cmd_$sub" "$@" } ``` `shift` then `"$@"` is the clearest spelling. The slice form `"${@:2}"` does the same without mutating the list, and `"${@:2:3}"` takes three arguments starting at the second — both keep the per-word quoting property, but only while quoted. ## Related idioms worth knowing `for x in "$@"` iterates arguments safely, and a bare `for x; do ...; done` means exactly that — the `in` list defaults to `"$@"`. Copying arguments into an array with `args=("$@")` and expanding it as `"${args[@]}"` follows the same quoting rule, which is why the two look so similar.