From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2982 invoked by alias); 30 Sep 2016 08:50:45 -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: 39515 Received: (qmail 1525 invoked from network); 30 Sep 2016 08:50:45 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.12):SA:0(-3.0/5.0):. Processed in 0.512073 secs); 30 Sep 2016 08:50:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f5-f79ce6d000004c54-e4-57ee275ba5b3 Date: Fri, 30 Sep 2016 09:50:32 +0100 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Strange parameter visibility Message-id: <20160930095032.17083e7b@pwslap01u.europe.root.pri> In-reply-to: <160929142821.ZM16694@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+NgFnrNIsWRmVeSWpSXmKPExsWy7djP87rR6u/CDZa+0LU42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGb8eKxe8E6m4snECawPjHoEuRk4OCQETiXm/p7FB2GISF+6t B7K5OIQEljJKHLi2A8rpZZI4vLeRHaZjxpNGRojEMkaJKy83MoEkhASmMUn8fGMCkTjDKNE3 YT5U+1lGib3/frGAVLEIqEo8W98OtpBNwFBi6qbZQKM4OEQEtCXaP4qBhIUFNCU2rHwIVsIr YC+x5k8bM4jNKWAl0fp7M5jNL6AvcfXvJyaIi+wlZl45wwhRLyjxY/I9sFXMAjoS27Y9Zoew 5SU2r3nLDHKPhEAzu8TVo9NZQfZKCMhKbDrADDHHRWLmwb3QsBCWeHV8C9THMhKXJ3ezQNj9 jBJPun0h5sxglDh9ZgdUg7VE3+2LjBDL+CQmbZvODDGfV6KjTQiixEPi5K2njBC2o8T7X1tY JjAqzkJy9iwkZ89CcvYCRuZVjCKppcW56anFpnrFibnFpXnpesn5uZsYgUng9L/jX3cwLj1m dYhRgINRiYdXQPltuBBrYllxZe4hRgkOZiUR3mMq78KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 8+5ZcCVcSCA9sSQ1OzW1ILUIJsvEwSnVwNgzyZ1Ju3+dlqXuy/BfN2s6NuSv3um0rdPNWSPm LZ/xxLtdX12/sU3b+8vo277W936fSq7v/80l7nR2X+axOkHH9pOOj/6FT5jx+7VJaf36qVmb d3I+XZDYnLq45uiUiS/Osr4OFV827Zkhj2FgEp/B1OuLXRrquDfluqo5xDs8ejTXReKCkrsS S3FGoqEWc1FxIgALdnzG/gIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVy+t/xa7oG6u/CDc5+U7I42PyQyYHRY9XB D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw cA5wD1bSt0twy/j1WLngnUjFlY0TWBsY9wh0MXJySAiYSMx40sgIYYtJXLi3nq2LkYtDSGAJ o8Srn1dYIJwZTBIfz/yDypxjlJj38CMrhHOWUeLFjdVMIP0sAqoSz9a3s4HYbAKGElM3zQaa y8EhIqAt0f5RDCQsLKApsWHlQ7ASXgF7iTV/2phBbE4BK4nW35uZIWbOYpJY39nADpLgF9CX uPr3ExPEffYSM6+cYYRoFpT4MfkeC4jNLKAlsXlbEyuELS+xec1bsKFCAuoSN+7uZp/AKDwL ScssJC2zkLQsYGRexSiSWlqcm55bbKRXnJhbXJqXrpecn7uJERhF24793LKDsetd8CFGAQ5G JR5eAeW34UKsiWXFlbmHGCU4mJVEeI+pvAsX4k1JrKxKLcqPLyrNSS0+xGgKDJiJzFKiyfnA CM8riTc0MTS3NDQytrAwNzJSEued+uFKuJBAemJJanZqakFqEUwfEwenVANjOqvT4jcyFrox hfXdFeq2+88zqV7Y8Ei06e5rT2uB3uOe7Kx7YsUOPldy5Nb99UZx1aakdRlr3QPbBNgn+K0r ruC0s3XMcGtL1n4uFqL0dOrkmdufNkcKn9pqOff6xcutVW/OxZgLGdw/UH04Zsdbq+19vUJx 7Q8/sFdoV7NXeiz4m3TR76QSS3FGoqEWc1FxIgBq2nXXuAIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160930085035eucas1p28ea44b822d93dcd73b944d1a5ce9b810 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20160917181339eucas1p24d214aa618aa96b5a8ddfbf351598da6 X-RootMTR: 20160917181339eucas1p24d214aa618aa96b5a8ddfbf351598da6 References: <87bmzmtmzq.fsf@alfa.kjonca> <20160929172417.5022a014@pwslap01u.europe.root.pri> <20160929180301.5d1930d0@pwslap01u.europe.root.pri> <160929142821.ZM16694@torch.brasslantern.com> On Thu, 29 Sep 2016 14:28:21 -0700 Bart Schaefer wrote: > On Sep 29, 6:03pm, Peter Stephenson wrote: > } Subject: Re: Strange parameter visibility > } % unset x > } % : ${x:=2} | echo $x > } 2 > } > } In this case, we don't know at the point where we start the pipeline > } whether we're going to be in the current shell or not. > > Hrm. But: > > % y=3 : ${z:=2} | echo $y $z > > % > > Why do we know *there* that we should fork before expanding ${z:=2}, > when we don't know in the absence of the y=3 prefix? Or is something > completely different happening, e.g., save_params() / restore_params() > that I was looking at before? That LHS turns up in execpline2() as WC_ASSIGN, which I've just changed (if you're using the change I put in). I wonder if that means there are cases where the change is problematic --- I hadn't realised this also covered assignments before running a command. Given your experience elsewhere, you might find this makes pipestatus worse if you test it on relevant shell code, for example. > Under what circumstances is it possible to do anything useful with a > pipe without forking the left side? The interesting thing --- which goes back into history and I've never properly got my head round --- is how the fork at that point interacts with the fork inside execcmd(). If it's a simple command being run you'd have thought we either fork there or above, and not both, but I'm not sure about that (and I'll need to check if that just got changed with WC_ASSIGN with an external command --- if there's a double fork for an external command I'll need to back that off, or think about introducing WC_ASSIGN_ONLY). One clue is the "output" parameter passed into execccmd() that says if we're talking to a pipe. That's used in the fork decision with the big comment around exec.c line 3166: if we're executing a builtin or a shell function and we're outputting to a pipe, we fork there. I think the reason we *don't* fork there for is_cursh is exacxtly because of that test in execpline2() --- we knew at that point it was shell builtin code, so didn't need to defer the decision. We needed to defer the decision if we hadn't analysed the command to see if it was a builtin or not. If it's not a builtin or current shell structure of some sort, we always fork down in execcmd() (unless exec'ing). Another ingredient here is the position of prefork(), the clue being in the name, which is where the ${z:=2} assignment takes place. If you're not confused, I haven't correctly transferred all the limited information I do have... pws