From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22514 invoked by alias); 18 Nov 2015 14:13:34 -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: 37137 Received: (qmail 26652 invoked from network); 18 Nov 2015 14:13:32 -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 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79026d00000418a-2b-564c8788c0ca Date: Wed, 18 Nov 2015 14:13:23 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in alias expansion Message-id: <20151118141323.04bda5aa@pwslap01u.europe.root.pri> In-reply-to: <20151118104254.4a46d326@pwslap01u.europe.root.pri> References: <20151115200356.0f3a80a2@ntlworld.com> <151115144805.ZM20614@torch.brasslantern.com> <20151118104254.4a46d326@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsVy+t/xy7od7T5hBisWq1ocbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujI/z3AumcVfsub6XpYHxDUcXIyeHhICJROvGLawQtpjEhXvr 2boYuTiEBJYySlw/e5kVwpnBJLHh2wMmCGcbo8S57RvBWlgEVCX2NO5lBrHZBAwlpm6azQhi iwiIS5xde54FxBYWUJZYcWACWA2vgL3EhFXXwWxOAQeJ7kdH2SGGPmSUeN96mAkkwS+gL3H1 7ycmiJvsJWZeOcMI0Swo8WPyPbChzAJaEpu3NbFC2PISm9e8BRsqJKAucePubvYJjEKzkLTM QtIyC0nLAkbmVYyiqaXJBcVJ6bmGesWJucWleel6yfm5mxghYftlB+PiY1aHGAU4GJV4eBMW e4cJsSaWFVfmHmKU4GBWEuHVrvYJE+JNSaysSi3Kjy8qzUktPsQozcGiJM47d9f7ECGB9MSS 1OzU1ILUIpgsEwenVANjbNzuDQK38+zfBbsx/3D/yaimtWbj2Q2nfNwczv++w3MvZp75DfGO 1Wfnda36eH0518L72g0Ga27uOxp2mP1TB4cg6+OLCauF9rrfkz937PGdudrLE1S3huj8qOee we9k9ii9eqHejb9/k72rmBPWLtOTPNV4g+XChIv/7zCKSygHmWpsU5y8XImlOCPRUIu5qDgR AA4q6JVXAgAA On Wed, 18 Nov 2015 10:42:54 +0000 Peter Stephenson wrote: > > Addendum: To some extent it does not. > > > > torch% alias foo='echo x)$(:' > > torch% print $(foo) > > zsh: command not found: fooecho > > This is a completely different problem again. There appear to be three > different but interacting issues: > > - this one, which could be hairy as we emerge from parsing a $(...) > expansion with an alias unpopped --- I'm not sure yet if that's > tractable without making the code yet more unreadable Actually, now I start looking, I think I'm inclining to Mikael's view on the interaction between this and the position of alias expansion, even if it's global. At the top level we have $(, foo, ). foo clearly starts within the $(. So it's hard to see how the $( can then end within the foo; it seems to violate the hierarchy. Yes, I know aliases can violate hierarchies, but only once they're expanded, obviously. I can't see a sensible reason for expanding foo until we're already within the context of the $(...) --- surely the intention of $(...) is to protect the outside world from whatever's inside, and if foo isn't inside I'm no longer sure which way up I am. Currently we expand both when parsing the entrails of the $(...) and executing it, but should possibly only do so in the latter case. I haven't look to see if this affects any tests. pws