Return to Answer

As far as I know, there are only two cases in which it is necessary to double-quote expansions, and those cases involve the two special shell parameters "$@" and "$*" - which are specified to expand differently when enclosed in double-quotes. In all other cases (exluding, perhaps, shell-specific array implementations) the behavior of an expansion is a configurable thing - there are options for that.

People often say the shell is a glue, and, if this is true, then what it is sticking is lists of arguments - or fields - to one process or another when it execs them. Most shells do not handle the NUL byte well - if at all - and this is because they're already splitting on it. The shell has to exec a lot and it must do this with a NUL delimited array of arguments that it hands to the system kernel at exec time. If you were to intermingle the shell's delimiter with its delimited data then the shell would probably screw it up. Its internal data structures - like most programs - rely on that delimiter. zsh, notably, does not screw this up.

As far as I know, there are only two cases in which it is necessary to double-quote expansions, and those cases involve the two special shell parameters "$@" and "$*" - which are specified to expand differently when enclosed in double-quotes. In all other cases (excluding, perhaps, shell-specific array implementations) the behavior of an expansion is a configurable thing - there are options for that.

People often say the shell is a glue, and, if this is true, then what it is sticking is lists of arguments - or fields - to one process or another when it execs them. Most shells do not handle the NUL byte well - if at all - and this is because they're already splitting on it. The shell has to exec a lot and it must do this with a NUL delimited array of arguments that it hands to the system kernel at exec time. If you were to intermingle the shell's delimiter with its delimited data then the shell would probably screw it up. Its internal data structures - like most programs - rely on that delimiter. zsh, notably, does not screw this up.

Unless quoted, $IFS is itself an $IFS delimited shell expansion. It defaults to a specified value of <space><tab><newline> - all three of which exhibit special properties when contained within $IFS. Whereas any other value for $IFS is specified to evaluate to a single expanded field per expansion occurrence, $IFS whitespace - any of those three - is specified to elide to a single field per expansion sequence and leading/trailing sequences are elided entirely. This is probably easiest to understand via example.

...is issued to the shell. Double-quotes - as they also do for field-splitting - render this global setting unnecessary per expansion. So:

Unless quoted, $IFS is itself an $IFS delimited shell expansion. It defaults to a specified value of <space><tab><newline> - all three of which exhibit special properties when contained within $IFS. Whereas any other value for $IFS is specified to evaluate to a single field per expansion occurrence, $IFS whitespace - any of those three - is specified to elide to a single field per expansion sequence and leading/trailing sequences are elided entirely. This is probably easiest to understand via example.

...is issued to the shell. Double-quotes - as they also do for $IFS field-splitting - render this global setting unnecessary per expansion. So:

• input words are the shell syntax items such as $word or echo $words 3 4* 5

• excepting "$@", $IFS field-splitting, and pathname expansion an input word must always evaluate to a single field.

3. expand those if necessary into multiple fields

• fields result from word expansions - they make up the final executable command

• input words are the shell syntax items such as $word or echo $words 3 4* 5

• words are always split on whitespace - that's just syntax - but only the literal whitespace characters served to the shell in its input file

3. expand those if necessary into multiple fields

• fields result from word expansions - they make up the final executable command

• excepting "$@", $IFS field-splitting, and pathname expansion an input word must always evaluate to a single field.