Re: issue with [[ -v A[\$k] ]]

[Kerin Millar]

On Sun, 21 May 2023 22:35:03 +0200
alex xmb ratchev <fxmbsw7@gmail.com> wrote:

> i made some simple dup file by checksum remover
> however the [[ -v assoc[\$var] didnt work
> 
> maybe due to your announced changes
> i dunno
> i cant track or much understand that english
> 
> to pre explain my code
> a is arr with files ( non dirs ) by find "$@"
> h is the same file mapping but in hashes
> first a is first h .. and so on
> if #a != #h exit with err ( i fast exec i dont care )
> 
> then interate from keys h ( or a , same .. )
> and in there i like used to , did [[ -v assoc[\$key] ]]
> but to my surprise it didnt work
> .. i have declare -n for short"
> but after z=$key to plain var , it still didnt work
> after removing the backslash before $key it worked
> i figured i d try ${key@Q} as key but it also didnt work
> 
> so ..
> [[ -v assoc[$key] ]] .. without \ works
> rest not anymore ?
> 
> whats the non eval version of assoc [[ -v
> is it already

One way is to write [[ -v 'assoc[$key]' ]], which, if I recall correctly, 
should work in both 5.2 and prior releases.

Generally speaking, bash is afflicted by a range of defects concerning the 
expansion of associative array subscripts. Every once in a while, certain 
behaviours end up being (arguably) improved in a manner that is difficult to 
reason with other than through trial and error. Meanwhile, workarounds 
previously known to be 'good' are rendered ineffective, thereby breaking 
existing scripts. The release notes for 5.2 allude to the latest round of 
attempts:

"The shell attempts to do a much better job of parsing and expanding array 
subscripts only once; this has visible effects in the `unset' builtin, word 
expansions, conditional commands, and other builtins that can assign variable 
values as a side effect."

As Greg mentioned in his reply, test -v is commonly misapplied and the way in 
which subscripts are treated in the arithmetic context has been significantly 
affected (though that is not the exact use case that you raised). At this 
juncture, I can only agree with him; these features of the language are 
unstable. Moreover, the workarounds that are effective today may not be 
effective tomorrow. All in all, the avoidance of these features should result 
in scripts that are markedly more likely to be forward-compatible.

-- 
Kerin Millar