On Thu, Jul 04, 2024 at 09:08:21PM -0400, Dale R. Worley wrote:
> Emanuele Torre <torreemanue...@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.
>
I don't really understand what you are trying to say here; anyway what I
meant was just that ${a[*]@A} always expands to 'declare -a foo=(bar)'
even though "${a[@]@A}" expands to 'declare' '-a' 'foo=(bar)'; it does
not expand to 'declare-afoo=(bar)' (for IFS=) or
'declarez-azfoo=(bar)' (for IFS=z). I find that surprising.
> 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
No, that is not how ${[@]@A} should work since you are supposed to run
it as a command ( "${foo[@]@A}" ). Anyway, [@] should not be
influenced by IFS. This is obviously a bug.
Whether the intended behaviour was:
* to make both "${a[*]@A}" and "${a[@]@A}" always expand to 'declare -a
foo=(bar)' regardless of IFS, and you are actually supposed to use the
result as eval -- "${a[@]@A}"
* to make "${a[@]@A}" expand to separate values as it is doing now (so
that "${a[@]@A}" works as a command)
* to make "${a[*]@A}" always expand as space concatenated results of
"${a[@]@A}"
* to make "${a[*]@A}" always expand as IFS concatenated results of
"${a[@]@A}"
I don't know; but definitely that IFS=z makes "${a[@]@A}" expand how
"${a[*]@A}" is currently expanding is not intended.
o/
emanuele6
