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

[Zachary Santer]

Was "Re: nameref and referenced variable scope, setting other attributes"

On Mon, Mar 18, 2024 at 4:20 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 3/14/24 8:57 PM, Zachary Santer wrote:
> >
> > While we're kind of on the subject, I find it really odd that the
> > ${var@A} parameter expansion will expand to either an assignment
> > statement or a 'declare' command, depending on whether or not the
> > variable has an attribute set.

First of all, my use case for ${var@A} is actually passing associative
arrays between processes like they're JSON, so probably not the use
case you had in mind. I couldn't figure out how to get this to work
until I knew bash a lot better and tried ${assoc[*]@A}. In any case,
for a scalar variable, I'll just pass the value from one process to
the other, and the receiving process knows what it's supposed to be.

This will look like
printf '%s\x00' "${assoc[*]@A}" >&"${fd}"
in modern bash, or
{
  declare -p assoc
  printf '%s\x00'
} >&"${fd}"
in bash 4.2, which I'm actually pretty happy with.

In either case, the receiving end evals what it receives, as you would expect.

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.

> Yes. There is one thing missing: the transformation should expand to a
> `declare' command when applied to a local variable at the current scope,
> even if there are no attributes to be displayed. Agreed?

Again, my prefered solution would leave it up to the bash programmer
whether they want a declare command or an assignment statement. 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.

Honestly, I don't know if I ever fully considered the scope
implications of eval'ing declare commands like I am. Looking over
things again, I might have gotten lucky that this approach never
created a shadowing declaration for me.

> I am less convinced about outputting a `-g' for a global variable when
> called from a function scope, but I could be persuaded.
>
> Because of dynamic scoping, users will always have to be careful about
> using this expansion on variables that might be local variables at a
> previous function scope. I suppose it depends on the desired meaning of
> `recreate parameter'.
>
>
> > You'd think you'd want a parameter transformation that always expands
> > to a 'declare' command, and maybe another one that always expands to
> > an assignment statement.
>
> Most of the time there isn't a difference between `declare a=b' and `a=b'.

If people don't use functions most of the time.