Re: ${var@A}; hypothetical, related parameter transformations

[Zachary Santer]

On Mon, Mar 18, 2024 at 6:26 PM Zachary Santer <zsanter@gmail.com> wrote:
>
> I guess, in bash 5.1+, it could pass
> "${assoc[*]@K}"
> and then the receiving end could
> eval "assoc=( ${assoc_message} )"
> if I wanted to avoid declaring the associative array anew.

If I wanted to duplicate an indexed array, however, whether in sending it
to another process or not, I would need to be able to expand only the right
hand side of the compound assignment statement, i.e. ( [5]="Hello"
[12]="world!" )

> For my
> use case, if, for whatever reason, bash decided to send associative
> arrays as compound assignment statements without being in the context
> of a declare command, the receiving end would have to have already
> declared the associative array variable before eval'ing what it
> received. Given that the documentation doesn't specify when bash would
> choose to generate an assignment statement vice a declare command,
> maybe that would be the safe way to go.

Just changed what happens on the receiving end to:
eval "${assoc_message#declare * }"
to ensure the associative arrays only get declared where I want them to be.

I could have done
eval "assoc=${assoc_message#*=}"
expanding to only the right hand side of the compound assignment statement.
This seemed redundant in my case, because the associative arrays are named
the same thing in both sending and receiving processes.

So I can get a couple of the things I want by manipulating what I get out
of ${var@A} with fairly straightforward parameter expansions. If I needed a
declare command and wasn't sure if I would get one, I haven't found a way
to expand that to something that is guaranteed to be a declare command
maintaining attribute settings. I think you're stuck using an if block at
that point.