Zsh Mailing List Archive
Messages sorted by:
Re: [PATCH] (take two?) typeset array[position=index]=value / unset hash[$stuff]
- X-seq: zsh-workers 48989
- From: Stephane Chazelas <stephane@xxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH] (take two?) typeset array[position=index]=value / unset hash[$stuff]
- Date: Wed, 2 Jun 2021 17:02:06 +0100
- Archived-at: <https://zsh.org/workers/48989>
- In-reply-to: <CAH+w=7aCikLxobxVR9g7Cp3S_LxyY_1hm0LHU8-M0QGSj2JNfA@mail.gmail.com>
- List-id: <zsh-workers.zsh.org>
- Mail-followup-to: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- References: <email@example.com> <CAH+w=7bHxSbFr60ZU0+oZ6+qEejhfBYTzvL7=aXadY5XzWtSzw@mail.gmail.com> <firstname.lastname@example.org> <CAH+w=7ZqE2DnxpHhvCjZnXB4A1vJ=EKB2fpWyUMaZX0VYqU9kg@mail.gmail.com> <CAH+w=7bVn2LiTsq194GjshVSOCSib7t4T=uZQ2ZvUGu6Z2XoPw@mail.gmail.com> <email@example.com> <CAH+w=7a+M7nTTqzmve+SZHwtEeRPTicQB5ZRy2XO6er4UhMb1w@mail.gmail.com> <CAH+w=7Z4RTLsEujWFyvDHZ+GVwiRcSk+p15qgDEPD0dbQwaxOw@mail.gmail.com> <firstname.lastname@example.org> <CAH+w=7aCikLxobxVR9g7Cp3S_LxyY_1hm0LHU8-M0QGSj2JNfA@mail.gmail.com>
2021-06-02 07:52:25 -0700, Bart Schaefer:
> > I have to admit I don't see the problem here. I would have
> > thought allowing a=foo and unset 'a' would be no-brainers
> Mostly I was thinking about
> key=$(some derived value)
> unset "hash[$key]"
> In existing code that would fail on [[ -z $key ]], but you can't see
> that by examination.
Not sure I follow. That script doesn't work properly atm as it
fails to unset the corresponding hash element and would be fixed
once we allow unset 'hash'
I can't think of real life scenarios where one would *rely* on
Aborting the shell with a
zsh:unset:1: hash: invalid parameter name
> > as there's no concern about backward compatibility as those
> > currently return an error.
> That's not our usual criteria for backward compatibility. Usually we
> only change things if the new construct was previously a syntax error,
> something that would prevent an old script from even being properly
By that logic, we could never add features like new options to
builtins or new flags. For instance, we couldn't add a -k option
to unset because
unset -k key arr
currently is not a zsh syntax error, that script is parsed OK,
and that command returns with:
unset: bad option: -k
> > Even for plain arrays, IMO, it would make sense to allow empty
> > subscripts. In most contexts, an empty arithmetic expression is
> > interpreted as 0:
> But ... there's no such thing as array position 0 in native zsh.
But it would make the API more consistent if array subscripts
could be any arithmetic expressions or comma-separated pair of
And when ksharrays is not enabled a to return the same error
as for a or a[empty] ("assignment to invalid subscript
Note that 0 position is allowed in second place:
for instance (or a[2,empty]=x, but not a[2,]=x atm) to insert a
x in second position.
I'm not saying that's something we should do or would be
terribly useful, just that it would make the interface more
consistent, and that array being rejected should not be a
justification for rejecting assoc.
> > The fact that (e) is recognised and (ee) is
> > not also makes for a not very consistent API.
> What would (ee) mean?
The e flag passed twice.
echo $a[(e)*], $a[(ee)*], $a[(eee)*]
All expand to element of key "*".
Messages sorted by: