Zsh Mailing List Archive
Messages sorted by:
Re: [PATCH (not final)] (take three?) unset "array[$anything]"
- X-seq: zsh-workers 49014
- From: Stephane Chazelas <stephane@xxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Cc: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH (not final)] (take three?) unset "array[$anything]"
- Date: Fri, 4 Jun 2021 09:02:00 +0100
- Archived-at: <https://zsh.org/workers/49014>
- In-reply-to: <CAH+w=7bjefwczt_YaUFK+aGno4G6mJKjnozgj280KBdBH94awA@mail.gmail.com>
- List-id: <zsh-workers.zsh.org>
- Mail-followup-to: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CAH+w=7bDA-nOH-OX1M9fCGACavpf=kN9rMYqN9vmBUZ+YrxRYQ@mail.gmail.com> <CAH+w=7a3hgsag-1WsLxn1yTUja8ooZ+K4eFQhNzHKc32o4a3yg@mail.gmail.com> <CAH+w=7ZMDn-_sfr_5ebDXhNeqC33traLow_hqu6y2=+Rbkij2g@mail.gmail.com> <CAH+w=7ZQ40EeuaNvLdFPzysHzvQe_QKKAeLjY9kbR23OJqK1KQ@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <CAH+w=7bjefwczt_YaUFK+aGno4G6mJKjnozgj280KBdBH94awA@mail.gmail.com>
2021-06-03 11:12:19 -0700, Bart Schaefer:
> > If I understand correctly, the "stripquote" variant is the one
> > where the user can do:
> > That is where quotes are parsed and removed but otherwise
> > serve no purpose.
> I guess you can describe it that way, yes.
It also means the lexer, a large and complex bit of code whose
behaviour also depends on a the setting of a number of options
will end up being exposed to user-supplied data (of the users of
the zsh scripts, not just the users of zsh), which adds some
level of risk.
> > That hardly helps with backward compatibility as users who did
> > work around the previous behaviour will still have to adapt
> > their work around
> The point of my previous analysis is that they probably will not have
> to adapt. Your $MATCH workaround operates correctly with the
> stripquote version in nearly as many cases as it currently does (it is
> not foolproof for the current shell implementation).
If I understand correctly, that quote stripping removes one
level of quotes from tokens identified as string tokens provided
the lexer succeeded in tokenising the input, so any workaround
would have to escape/quote any shell special character to
guarantee the lexer succeeds.
> I agree that the literal variation is probably the one most useful to
> re-apply in cases like read, print -v, etc.
Note that read/print -v, etc. is radically different.
Currently we can do (reliably):
and can't do (reliably)
If we align with whatever solution we pick for unset, we're
going to break a lot more scripts. I don't think we can touch
those at least in the default mode operation.
Messages sorted by: