Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH] (?) typeset array[position=index]=value

2021-06-01 09:05:13 -0700, Bart Schaefer:
> > [...] unless we're happy to break backward
> > compatibility and make unset "assoc[$key]" work whatever the
> > value of $key (unset 'assoc[f\]oo]]' for unset the element of
> > key 'f\]oo]' for instance)
> Hm, I'm not sure what backward-compatibility would be broken?  Do you
> mean that scripts that already have work-arounds for the current issue
> might stop working?

Yes, like that guy's unset_keys at
mentioned earlier.

ATM, you need to do:

unset 'hash[\]]'

To unset the element of key "]" for instance.

Having said that, in practice, it's rare for values to be passed
literally. What you generally want to do is:

unset "hash[$key]"

With $key being any arbitrary string. And that's where the
problem is.

Maybe the best approach would be to make unset a dual
keyword/builtin like typeset/export... so one can do:

unset hash[$key]

And that hash[$key] being interpreted the same as when you do:


Being able to do:

unset hash[(R)pattern]
unset hash[(I)pattern]

would also be useful. We don't want however subscript flags to
be interpreted in:

unset "hash[$key]"

as that would introduce command injection vulnerabilities, like
is already the case in things like:

$ key='(n:evil:)' evil='psvar[$(uname>&2)1]' zsh -c 'typeset -A a; (( a[$key]++ ))'

(though in that case, that's not limited to subscript flags,
key='x]+psvar[$(uname>&2)1' works as well, see

That's also why I was suggesting allowing:


to unset an element, where you don't have the ambiguity of
whether the contents of $key is going to be interpreted


Messages sorted by: Reverse Date, Date, Thread, Author