From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16636 invoked by alias); 18 Nov 2015 16:24:44 -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: 37144 Received: (qmail 8079 invoked from network); 18 Nov 2015 16:24:43 -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-77-564ca3eaaecc Date: Wed, 18 Nov 2015 16:14:31 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in alias expansion Message-id: <20151118161431.360006a5@pwslap01u.europe.root.pri> In-reply-to: <151118075246.ZM28042@torch.brasslantern.com> References: <20151115200356.0f3a80a2@ntlworld.com> <151115144805.ZM20614@torch.brasslantern.com> <20151118104254.4a46d326@pwslap01u.europe.root.pri> <20151118141323.04bda5aa@pwslap01u.europe.root.pri> <151118075246.ZM28042@torch.brasslantern.com> 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/xK7qvFvuEGZxZzm1xsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mt5fvM9ecJe7Yl/zIaYGxo2cXYwcHBICJhLLr+R3MXICmWIS F+6tZ+ti5OIQEljKKHH391UWCGcGk8TySWegMtsYJR5fWswK0sIioCqx9O4CdhCbTcBQYuqm 2YwgtoiAuMTZtedZQGxhAWWJFQcmMIPYvAL2Eps/PQazOQWsJPZuWMsIMfQ4k8TclXPABvEL 6Etc/fuJCeIme4mZV84wQjQLSvyYfA9sKLOAlsTmbU2sELa8xOY1b8GGCgmoS9y4u5t9AqPQ LCQts5C0zELSsoCReRWjaGppckFxUnquoV5xYm5xaV66XnJ+7iZGSNh+2cG4+JjVIUYBDkYl Ht6Exd5hQqyJZcWVuYcYJTiYlUR4tat9woR4UxIrq1KL8uOLSnNSiw8xSnOwKInzzt31PkRI ID2xJDU7NbUgtQgmy8TBKdXAGO322a+R1SOyNWyRaOzb5S5iKe+kg/Nv1Fr8Ypy16IJxzI6g S1UpiuISiR9LF2cv6fWRnPEza3a5+PUlzW4fVmeISV3rPpcpn3VHqoQnPnPf5oZ5XzbueKde Xcgot/J/IGfBfPGOvujigLhfZw+sWSSeuDeXwTCSy+N8SCK/vdv7eu3XWmFKLMUZiYZazEXF iQARiiexVwIAAA== On Wed, 18 Nov 2015 07:52:46 -0800 Bart Schaefer wrote: > On Nov 18, 2:13pm, Peter Stephenson wrote: > } 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. > > Would not-expanding affect cmd_or_math() adversely? Is that why we > expand and then backtrack? I can't offhand think of a case. The crucial thing about cmd_or_math() is to get the parentheses right. Being affected by this change implies it's currently propagating the effect to some outer layer of expansion, which we're in the process of deciding is probably a bad thing. If this is correct it applies recursively, so nested expansions aren't an issue. Did you have some vague pointers in mind? I don't believe there's ever a case where we won't do the alias expansion when we finally execute the inside of a $(...), because it's always reparsed for execution (considered a bug up to now but getting us out of the present hole), and $((...)) is equivalent to math eval in double quotes, so no global aliases, if that's what you mean. Come to think of it, the name of the function dquote_parse() kind of implies we're not expanding aliases, but then it was named before we started handling $(...) better, so that's not a great pointer. Anyway, there are some pretty hairy tests, so if we change it we should find out quickly. pws