On Wed, Mar 20, 2024, 12:59 Greg Wooledge <g...@wooledge.org> wrote: > On Wed, Mar 20, 2024 at 12:53:07PM +0100, alex xmb sw ratchev wrote: > > On Wed, Mar 20, 2024, 12:49 Greg Wooledge <g...@wooledge.org> wrote: > > > > > On Wed, Mar 20, 2024 at 07:11:34AM -0400, Zachary Santer wrote: > > > > On Wed, Mar 20, 2024 at 12:29 AM Lawrence Velázquez <v...@larryv.me> > > > wrote: > > > > > A couple of previous discussions: > > > > > - > https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00066.html > > > > > - > https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00128.html > > > > > > > > There I go, reporting a bug that isn't a bug again. > > > > > > > > One would think that enabling this behavior would be the entire > > > > purpose of the alternate ( key value ) syntax. If it doesn't do that, > > > > what benefit does it give over the standard ( [key]=value ) syntax? > > > > Maybe it;s easier to use eval with? > > > > > > I believe the "X" in this X-Y problem is "I want to serialize an > > > associative array to a string, send the string to another bash script, > > > and de-serialize it back into an associative array there." > > > > > > > as 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.
that i used yes , in very few projects >