In bash, what is the difference between expanding an array as "${arr[@]}" and as "${arr[*]}", and what changes if you drop the double quotes from either one?

## The two subscripts An indexed array has two special subscripts that mean "all of it". They differ in how many *words* the expansion produces, and that difference only becomes visible once the expansion is quoted. ```bash arr=(one "two three") printf '[%s]\n' "${arr[@]}" # [one] [two three] printf '[%s]\n' "${arr[*]}" # [one two three] ``` `printf` reuses its format for each remaining argument, which makes it a good probe: two bracketed lines mean two arguments, one line means one. ## "${arr[@]}" — one word per element Inside double quotes, `[@]` is special-cased by the shell: instead of producing one quoted string, it produces a *list* of words, one per element, each individually protected from word splitting and pathname expansion. Whatever bytes are in an element — spaces, tabs, newlines, `*`, a leading `-` — arrive at the command as exactly one argument. This is the same rule that makes `"$@"` work for positional parameters; the array form is the general case of it. A useful corner: if the array is empty, `"${arr[@]}"` expands to *nothing at all* — zero words, not one empty word. So `mycmd "${opts[@]}" file` runs `mycmd file` when `opts` is empty, which is exactly what you want when building optional flags. ## "${arr[*]}" — one joined word `[*]` inside double quotes joins the elements into a single word, separated by the **first character** of `IFS`. With the default `IFS=$' \t\n'` the separator is a space, which is why the two forms look identical in casual `echo` output. Change `IFS` and the difference is obvious: ```bash arr=(a b c) IFS=, echo "${arr[*]}" # a,b,c ``` If `IFS` is unset, the join character is a space; if `IFS` is set to the empty string, the elements are concatenated with nothing between them. `"${arr[*]}"` is therefore the right tool for *display* and *serialisation* — a log line, an error message, a comma-separated field — and the wrong tool for passing arguments, because everything ends up in one argument. ## Dropping the quotes Unquoted, both forms first produce the elements as text and then hand the result to word splitting and pathname expansion, which is where data gets destroyed: ```bash arr=(one "two three") printf '[%s]\n' ${arr[@]} # [one] [two] [three] ``` The element `two three` was split into two arguments on `IFS`. Exactly the same thing happens with unquoted `${arr[*]}`. On top of splitting, each resulting word is a glob candidate, so an element that happens to be `*.txt` or `report[1].csv` can be replaced by matching filenames — or left as a literal that no longer matches anything. ShellCheck flags this as SC2068 ("double quote array expansions") for the same reason it flags unquoted scalars as SC2086. The practical rule is unconditional: **write `"${arr[@]}"` and never think about it again.** There is no realistic case where unquoted `${arr[@]}` is what you meant; if you genuinely want the elements re-split, you are building a string, and `"${arr[*]}"` says so explicitly. ## Mixing an array into a larger string One more trap sits between the two forms: ```bash echo "Args: ${arr[@]}" ``` A quoted `[@]` embedded in a longer string produces the first element glued to the prefix and the last glued to the suffix, with the middle elements as separate words — almost never what the author intended. If you want one readable string, use `[*]`: `echo "Args: ${arr[*]}"`. ## Slices and indices follow the same rule Every all-elements expansion inherits the distinction. `"${arr[@]:1:2}"` yields two words; `"${arr[*]:1:2}"` yields one joined word. `"${!arr[@]}"` — the list of subscripts — is a word list too, which is why iterating indices with it is safe. ## Summary `@` for arguments, `*` for a string, and always with the quotes. Everything else about arrays follows from getting this one right.