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

2024-03-19 Thread Lawrence Velázquez
On Tue, Mar 19, 2024, at 11:18 PM, Zachary Santer wrote: > As such, I would expect that > $ declare -A assoc_2=( "${assoc_1[@]@k}" ) > would create assoc_2 as a duplicate of assoc_1. However, we see that > the entire expansion becomes the key for a single array element, with > its value being the

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

2024-03-19 Thread Zachary Santer
On Tue, Mar 19, 2024 at 11:18 PM Zachary Santer wrote: > > Repeat-By: > > $ declare -A assoc_1=( [key 0]='value 0' [key 1]='value 1' [key > 2]='value 2' [key 3]='value 3' ) > $ unset assoc_2 > $ declare -A assoc_2 > $ printf '|%s|\n' "${assoc_1[*]@k}" > |key 2 value 2 key 3 value 3 key 0 value 0

Re: Bash printf should diagnose integer overflow

2024-03-19 Thread Paul Eggert
On 3/18/24 12:41, Chet Ramey wrote: I'm not sure what you're using, but that was not my experience on macOS. I am using Fedora 39 (the current version) on x86-64. That could explain our differing experiences. I see several diagnostics (mostly diff output) with "make check" on Fedora 39.

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

2024-03-19 Thread Zachary Santer
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: msys Compiler: gcc Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe -D_STATIC_BUILD uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.4.10.x86_64 2024-02-10 08:39 UTC x86_64 Msys Machine

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

2024-03-19 Thread Zachary Santer
On Mon, Mar 18, 2024 at 6:26 PM Zachary Santer 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,

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

2024-03-19 Thread Mike Jonkmans
On Tue, Mar 19, 2024 at 02:24:34PM -0400, Chet Ramey wrote: > On 3/19/24 11:50 AM, Mike Jonkmans wrote: > > > > 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

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

2024-03-19 Thread Chet Ramey
On 3/19/24 11:50 AM, Mike Jonkmans wrote: 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? I am less convinced about outputting a `-g' for a

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

2024-03-19 Thread Mike Jonkmans
On Mon, Mar 18, 2024 at 04:19:55PM -0400, Chet Ramey wrote: > On 3/14/24 8:57 PM, Zachary Santer wrote: > > On Thu, Mar 14, 2024 at 3:43 PM Chet Ramey wrote: > > > > > > In fact, before 2020, local -p with no name arguments behaved the same as > > > local without arguments, which just printed