Re: [@]@A weird behaviour when IFS does not contain space

[Dale R. Worley]

Emanuele Torre <torreemanuele6@gmail.com> writes:
> [...]
> Today, I have noticed that if IFS is set to a value that does not
> include space, [@]@A will expand to a single value
> [...]
> As an aside, [*]@A always expands to the declare command joined by
> space, even if the first character of IFS is not space; I think that is
> a bit confusing, and surprising, but maybe that is done intentionally:
> "intended and undocumented"(?).

IMHO, the second observation is what should happen:  The construct
"${a[*]@A}", like almost all variable expansions, produces a *character
string*, and then the characters are parsed into words and interpreted.
In this case, the string contains spaces between the characters that are
generated for each array member.  But if IFS doesn't contain a space,
then that string of characters isn't split into multiple words.

Although perhaps "${a[*]@A}" should operate like "${a[*]}" does
(according to my very old man page):

       If
       the word is double-quoted, ${name[*]} expands to a single word with the
       value of each array member separated by the first character of the IFS
       special variable, [...]

That is, the blocks of the result string should be separated by the
first character of IFS.

The first case is more complicated.  The man page says for "${a[@]}":

       [...] ${name[@]} expands each element of name to a sep‐
       arate word.

This is the one case where the results of a variable expansion can't be
modeled simply as replacing the variable reference with a string of
characters (which are then parsed).  It suggests that "${a[@]@A}" should
automagically generate a separate word for each element of the array a,
regardless of the value of IFS.

Dale