From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15650 invoked by alias); 18 Nov 2015 04:55:16 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37133 Received: (qmail 1369 invoked from network); 18 Nov 2015 04:55:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern_com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version:content-type; bh=+fv6g52/WTRIwHAkDdL0N192okHdMvHQ+YknBoTB+GU=; b=eZqenZAchpkX3cplC7hb8Gfr7G2pfCUtZ7PUQxy9TTksgGR0C2TyuMIeoDVDFsstQd spOF7Kd3svYPK+LY3qkAX1VFzSK8E2cjfpOcTQ//5B7vSVWZV9Rp3PD1SIqkwczi1pnH 47MjbTpfDLmBXLfQUAkATUyxx27Rsc0uB6eKfWY2FjL1UCQkUeLZicVoElX+g8Hw607c lEO80TL83CUw5en1PawARlNs/3EEV5CYTfmdZf5YtTVo4xWpen7vMIlUeNrSy5YyrlUd A+oA5LIwOHnbTL+k/4Lh+8P6w3fmscnx1SPMF5Q2nmkKnLpI1KfZrSODEIRWrcSrx8+j EUzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=+fv6g52/WTRIwHAkDdL0N192okHdMvHQ+YknBoTB+GU=; b=XUrIhPJxiHsMnRfO9RELePAB1SpV7aD3pUuTuc1F47MymMdPCzzZHpDrIdqH8yPKmj HqyJMjDnlK22Q6p05mI/kksCFa9AuL6DJhFWcLgdwh2ms1amgAiIITRrAhufqwQavty2 6PHpqIWm5kNy/BhtT6s9hASCOcDMUWsfPGt+7TrOP3/pofmjmJsKTQRYoDOVH2KKMAkO iJEgMfehess6DAv3LUjlFB0buTmJPGttYnmsV+BUUd3zEEIbGsq36cmFSTgN0XZAe6JI 05psq3rcR9HCHnDw9UfRkUs0KvSq7oVjUK1uUnmVWtcSdsLf5aF0jSP47igoFGlAjzpt 2q4w== X-Gm-Message-State: ALoCoQk/Ro1jJ+6BopARwWQuui8dtySwpjf7j7IWpdqFBDdPMzXgeKZwR3apJA464aat8MIlqDy4 X-Received: by 10.68.184.132 with SMTP id eu4mr69090635pbc.122.1447822510709; Tue, 17 Nov 2015 20:55:10 -0800 (PST) From: Bart Schaefer Message-Id: <151117205508.ZM26027@torch.brasslantern.com> Date: Tue, 17 Nov 2015 20:55:08 -0800 In-Reply-To: <20151117172951.01bf1825@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Bug in alias expansion" (Nov 17, 5:29pm) References: <20151115200356.0f3a80a2@ntlworld.com> <20151117172951.01bf1825@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Bug in alias expansion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 17, 5:29pm, Peter Stephenson wrote: } } We can get rid of the currently visible problems by allocating a new } string for the token and copying back the result to the original. A few remarks about this. (1) This doesn't resolve the problem I pointed out in workers/37123. (2) Referring to the discussion I've been having with Mikael (cf. workers/37126), with this patch the alias is expanded in the parent shell for "alias -g" and in the subshell without -g. When the $(...) expansion is NOT in subscript context, on the other hand, the alias expands in the subshell for both global and command aliases. (3) I'm fibbing in the last sentence of (2). The alias is expanded BOTH in the parent shell (which is where the "fooecho" bug from 37123 arises) AND in the subshell. In the parent shell the alias is expanded during the parse but then (in the case where it lexes correctly) the expansion is thrown away, only to be re-expanded in the subshell. Consequently ... either Mikael is right that the alias expansion should be forced into the subshell, your patch is thus "wrong," and my patch in 37122 is closer to what should happen; or the parent is responsible for the alias, and when we fix 37123 we should make the behavior outside of subscripts consistent with the behavior inside. (Of course 37128 and 37122 aren't mutually exclusive, we can apply both; there's probably some other case where subscript parsing may go wrong that's fixed by 37128.) } It's not very efficient, and it still has the problem that if something } funny happens to the length --- and I don't think there's any guarantee } of length preservation built into the lexer even though it happens to } work in the cases we've looked at so far --- then somebody's going to } get hurt. I'm not following this stuff about the length -- it can't mean that the length of the alias expansion is the same as the length of the aliased token -- so to what does it refer?