Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

[Léa Gris]

Le 20/03/2024 à 12:59, Greg Wooledge écrivait :

s to that , simply declare -p and run that back
> That will work in some cases, yes.  The problem is that it locks you
> in to having the same array name and the same attributes (if any) as
> the original array had.  It also runs "declare" which can create issues
> with scope, if it's done inside a function.  Perhaps you wanted to
> populate an array that was previously declared at some scope other
> than your own, and other than global (which means adding -g wouldn't
> work either).
>
> I suppose you might argue that you could run declare -p, and then
> edit out the "declare" and the attributes, and then while you're at it,
> also edit the array name.  I guess that's a possible solution, but it
> really seems ugly.

I agree about the ugliness and all the potential issue with interpreting 
what is basically code subject to any kind of expansion inherited from 
another unknown source.

I think Bash shall not try to implement its own serializations with 
expansion. PHP Had the exact same design issue with embedded 
serialization and it causes enough issue that all modern code choose 
JSON serialisation and JSON has been made part of PHP.

A couple years ago I read here about future Bash becoming modular or 
something along this with a module for JSON.

I'd have preferred for Bash to have some internal support for JSON even 
if there is no compatible nested structure. But at least expand values 
as strings and if anything else put the JSON text string as the value.

But possibly people are overusing Bash and shell for things that it was 
not designed for. In a lot of case, more general purpose scripting 
language are available to a wide range of systems.

When your favorite tool is a hammer, problems tend to look like nails.

--
Léa Gris