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

[Emanuele Torre]

On Thu, Jul 04, 2024 at 09:08:21PM -0400, Dale R. Worley wrote:
> 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.
> 

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