Re: uninvited members of associative array

[Lawrence Velázquez <larryv@xxxxxxx>]

On Thu, Dec 15, 2022, at 9:56 PM, Ray Andrews wrote:
> On 2022-12-15 18:09, Dominik Vogt wrote:
>> Probability of 95% or more that the array gets modified after the
>> initialisation by some stray code.  Put prints all over the place
>> to find the place where the array gets modified.
>
> Nope, I showed the output directly after the init.  If something goes 
> wrong, it goes wrong during the init itself.

Or before.


> Lawrence:
>
>> It makes no sense to question the code before verifying that your
> data isn't garbage.
>
> All the named keywords have exactly correct data, there's nothing not 
> to like as far as that.  Dunno, it wouldn't be the first time that 
> there was some silly issue in the printout, no real problem at all, so 
> my first question assumed nothing.

Wrong.  It assumed that "main" contained the expected data and
nothing extra.  I've already asked you to use "typeset -p" to verify
its actual contents, but you still haven't.


> I think I'm on the scent, the array is global.  If I zero it before all 
> the assignments (they're just numbers, no need to show the full 
> genealogy of them), then the interlopers disappear.

If you're implementing this in one of your sourced scripts, then
you should clear "main" anyway, or you risk reusing a preexisting
array.


> So now the 
> question is where the bogus elements come from.  They aren't actually 
> assigned anywhere, that's for sure.

I don't trust your judgment on this.


> Variable crosstalk?  How does an 
> associative array get corrupted?  Let me root around a bit ...
> hey ... you don't suppose a zcurses crash might do it?

It's far more likely that you've been using a preexisting array or
are inadvertently assigning to "main" from a function or your
dotfiles or another location you haven't considered than that you've
encountered a bug in zsh or zcurses.


-- 
vq