From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32331 invoked from network); 3 Jun 2021 06:06:24 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 3 Jun 2021 06:06:24 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1622700384; b=uQiOkAtu6x5GQQvna0kPP6AiozjqfEIGjfI7xdK+k+bHFdiWj3mH8eZXrBGwV6VVnUEkWKmrNS 9aWLXFr7BA33aR1NH7GaTjeDTORbNWV38tQKMENDF7G2XcTD1qoosPbNbO9mu8yr1KY05+QIPK x7qTWmfkgbCDTmNNEYnWPdHx0Siu+XHcL+3UzQRBdI0JQmYFYMii1MliFe0H3g/RLJPr9IkktZ SJeSlODaWFa+LIT4URbSi/+/YfEsN5bw1Zr3hO3CyxgF0ucKoaW+wVCY36JiosyqWepKkclyRV t9LV4sDVqzKYva97UWiX0V+tvWzvBdzmLg8O9qZY68Q1Yw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (relay2-d.mail.gandi.net) smtp.remote-ip=217.70.183.194; dmarc=none header.from=chazelas.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1622700384; bh=6oB+6p1iVW8Q0fVEsGVL60M2BFsQv7SERtcqN0umSmk=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:DKIM-Signature; b=JZZCch1l7tw/pCADuAZ9dzSdrCe2f5FuoLnPYIHM1i41uNRUz6Rdvdp0nVm1yi0Kc8J9Yd4feX J/UUa0pye0kqQbCvQHgl0yvJ1zUuUx9HBWIndLBBxKPMKeLrKbXfKu+drrs0FzAU8jqDmiuV6m zFPaACJyawUXYNW87DJAhEc8ykFH4sXj55Aygg32Tu4xkkSKHALO0LP64gGxY21eAxS0M7Ig/O 64jfRQpDghJzU+jWeu2t5OaqdZStzkeeIM9DK6Fei3qxabvJt3q5NySdH6XsfxwfxCQ+bSF8mj gYASbmbvtPkt/IUNAxS7D8n1qttPDOoTY4LiwSJD2hBgxQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=BI/Jj0IoXn0oxAoz822ia/0toXVKb6yc0yJabCWLa2A=; b=QiGHUl9HQFzJXy9IGmZh0fTPAq KLf9hO8tqCh3xTMFyhN78rQ2SF5DNnC/ZKRA1VFCRWZO8bUZ0UfgiJMnzJVpVP0jQ4Amd6T3kdLHy GPDINXG9UD6WhBf2wkNj2LIRxJXZmHMrGnbQa73n3/yDljILCB8K/tde46yhr9btDKPZ1G41mZTxf iDpbqGW+jfHQDKQOstpXhB0MaSFgbd6B5BA3d3LpC3C3FT2q+2Ms7uFeLthaKuTI3qM44QhnnbNk4 vJlzGkLUP9d1GrVbbdCP6hDgYaqXhI00ciuopYR80lOXPjpZLbDPIg9x52sE03rwwiKR/ybgV2nnn S8ghwXVg==; Received: from authenticated user by zero.zsh.org with local id 1logUo-000DEi-0w; Thu, 03 Jun 2021 06:06:22 +0000 Authentication-Results: zsh.org; iprev=pass (relay2-d.mail.gandi.net) smtp.remote-ip=217.70.183.194; dmarc=none header.from=chazelas.org; arc=none Received: from relay2-d.mail.gandi.net ([217.70.183.194]:59867) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1logUF-000Csz-M1; Thu, 03 Jun 2021 06:05:48 +0000 Received: (Authenticated sender: stephane@chazelas.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id F3E1240005; Thu, 3 Jun 2021 06:05:46 +0000 (UTC) Date: Thu, 3 Jun 2021 07:05:46 +0100 From: Stephane Chazelas To: Bart Schaefer Cc: Zsh hackers list Subject: Re: [PATCH (not final)] (take three?) unset "array[$anything]" Message-ID: <20210603060546.lvai62egrinwrbni@chazelas.org> Mail-Followup-To: Bart Schaefer , Zsh hackers list References: <20210505114521.bemoiekpophssbug@chazelas.org> <20210601053235.b4junj6muuwegl7b@chazelas.org> <20210602091145.xvyymjxdors6kqya@chazelas.org> <20210602142005.b5tw2hj2c6q3psqv@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Seq: 48997 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: 2021-06-02 19:04:01 -0700, Bart Schaefer: > On Wed, Jun 2, 2021 at 8:59 AM Bart Schaefer wrote: > > > > I've just had a hand-slaps-forehead > > moment ... take 3 to follow in another thread. > > What I realized is that for any unset of an array element, the closing > bracket must always be the last character of the argument. There's no > reason to parse the subscript or skip over matching brackets; if a '[' > is found, just make sure the last character is ']' and the subscript > must be everything in between. D'oh, I had assumed that had been like that in the beginning but changed to allow backslash processing for some reason or other such as alignment with something else. [...] > Given this realization, it's easy to make { unset "hash[$key]" } work > "like it always should have". The trouble comes in with (not) > breaking past workarounds. I think I'd be in favour of breaking these workarounds on the ground that it would fix far more existing script (that just do unset "hash[$key]") than it would fix. There's also the question of what to do with read "hash[$key]" getopts "hash[$key]" and getln, print[f] -v, sysread, strftime -s... I've not tested all of them but at least for read and print -v, key=foo typeset -A a print -v 'a[$key]' x gives: typeset -A a=( [foo]=x ) and not typeset -A a=( ['$key']=x ) With those, one can't do: read "hash[$key]" (which would be a command injection vulnerability) And the (unintuitive) work around is: read 'hash[$key]' It's the same in bash unless you set the assoc_expand_once option there, not in ksh93. My suggestion of making unset a keyword so that unset hash[$key] works as expected while unset "hash[$key]" works as before won't fly as we can't possibly make all builtins that take lvalues keywords. [...] > Therefore I think the best option is to choose one of the latter two, > possibly depending on which one induces the least damage to any > workarounds for the current behavior that are known in the wild, > though aesthetically I'd rather use the literal version. [...] Well, the only one that doesn't break workarounds is to leave it asis (and potentially add support for unset 'hash[]'), or introduce a new syntax (like unset -k "$key" hash) or an option like bash's assoc_expand_once to switch to the new behaviour. We can't really expect people to carry on doing: () { set -o localoptions +o multibyte -o extendedglob unset "hash[${key//(#m)[][\\()\`]/\\$MATCH}]"; } to unset a hash key, so I don't thing it's reasonable to leave it asis. Another option would be to align unset with the other builtins, but that's even more problematic as codes that were doing: unset "hash[$key]" would change from being buggy (choking on []()`\ and other characters containing the encoding of those) to being command injection vulnerabilities (like with bash without assoc_expand_once): $ echo x | key='$(uname>&2)x' bash -c 'typeset -A a; a[$key]=1; unset "a[$key]"; typeset -p a' Linux declare -A a=(["\$(uname>&2)x"]="1" ) $ echo x | key='$(uname>&2)x' bash -O assoc_expand_once -c 'typeset -A a; a[$key]=1; unset "a[$key]"; typeset -p a' declare -A a=() (zsh has the same problem with read/print -v...) And again, there is also the problem of hashes used in arithmetic expressions, including: key='evil $(reboot)' print -v 'array[++hash[\$key]]' x (here you need both the single quotes and the \ to avoid evaluations of code in the contents of $key) I must admit I don't really have an idea of how to get out of this mess. bash, which must have gone through a similar exercise, hasn't fixed everything with its assoc_expand_once (see https://unix.stackexchange.com/questions/627474/how-to-use-associative-arrays-safely-inside-arithmetic-expressions/627475#627475 again). -- Stephane