From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25946 invoked by alias); 8 Oct 2017 07:53:36 -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: 41828 Received: (qmail 25135 invoked by uid 1010); 8 Oct 2017 07:53:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-pg0-f52.google.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(74.125.83.52):SA:0(-1.9/5.0):. Processed in 2.73066 secs); 08 Oct 2017 07:53:35 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | 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; bh=vmONaoepU6HswHyoCGV+348vMLjYpwytXDyCpxWzGEA=; b=sJzBvBYLNTdIdf1m7L/bkVtNUSPp6YYzVWN71FGwur6WQv2ZtuF7SkBZDmovFRsm0j HQSCPFD8kv3kyds6aKVwEslRSfE9a8WzYlSRVAql1xFg0Prk/3dtcv2hw6N7LtyOtWE4 YNnV2ntQCyCGaK8+XQvnKdyFocfJesgfcjFH71Zy4NvGai28GSeJIH8o4x/ektgyjbQX KKouQaQbGbuLJmXrC0yLHx/GCF5B68IW35m/mYspeNRr4437ggaQhpFhyCuDNOm2VWAf UCBA/FXxNfR1LNbyNpr1TYuk5nS4QLTUgqbTMQyzcJmFu+4mPqD7Nx0qTBF2UEdIXeuj Mwsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=vmONaoepU6HswHyoCGV+348vMLjYpwytXDyCpxWzGEA=; b=DTgY2dtaFeaKzsVWLkMo8U06CYCYPbcjXTfwBuApa+F9vjLiORFHQfLDgHAcuwdEER 1sSCq1w//0GcnxROlkHfhbsSh2om4FioiX2OIuXOe843h6uZBtzA8dpJhr5Tw8oFD3Os 5p7uotKsx7xiqX1SXYDLCM5XupQlQPO43fnVRiU6n2XMNjyIv8hssrib3Y4KFSwOEVU+ Rij5UI4MO7R6XtHZWu7X9xClG6cXOl6Et8l/INVhPpNHpwPndaMsXfbntfytA7zSbgXu 2xW755qBCcdIDDwjEa+TKmJMtyK+9UP4Dm0C3hSVRrFpOlO25Uav8sZmeNBRqewcgZq8 JX4g== X-Gm-Message-State: AMCzsaUBk6NOVOlpuPsDw9NIIQTF6hkr8YHVMFZq6GcoIif//x+HoXs5 ufmAbNMmU4n5/UPHzd9cmCbd0hwR X-Google-Smtp-Source: AOwi7QCRulVNjNpsxaupj1bUKrk1/7DXlMsvl4IV7FGBulZ/QK95y/D12kLWMVs1pO4YG+JaKEadhw== X-Received: by 10.98.141.65 with SMTP id z62mr6835462pfd.186.1507449209620; Sun, 08 Oct 2017 00:53:29 -0700 (PDT) From: Bart Schaefer Message-Id: <171008005347.ZM1177@torch.brasslantern.com> Date: Sun, 8 Oct 2017 00:53:46 -0700 In-Reply-To: <06fb6a91-6766-bbd7-9543-cbafe704ee59@inlv.org> Comments: In reply to Martijn Dekker "[bug] sh: tilde expansion after field splitting" (Oct 5, 12:20am) References: <06fb6a91-6766-bbd7-9543-cbafe704ee59@inlv.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: [bug] sh: tilde expansion after field splitting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 5, 12:20am, Martijn Dekker wrote: } Subject: [bug] sh: tilde expansion after field splitting } } POSIX says tilde expansion should be done before parameter expansion [...] } zsh did this correctly up to version 5.0.8; as of 5.1, it appears to do } tilde expansion *after* field splitting, and only from the second field on. The patch below fixes this, I believe. Several comments: - There either isn't a Test/ for the keyvalpairelement() case in the first hunk below, or it isn't rigorous enough, because I initially forgot the incnode(node) in that hunk, yet the shell did *not* go into an infinite loop during "make check", nor did any test fail. - The patch covers two bugs for the price of one: unqueue_signals() near the end of the first hunk was missed when keyvalpairelement() was added (that's the only place at which errflag could become set at that point in the loop, and only when keyvalpairelemnt() also returns false). I'm guessing a test for that failure is needed? - Should we be testing isset(SHFILEEXPANSION) directly here, or ought it instead be [for example] passed in the flags? Is it possible that stringsubst() [second hunk] could toggle the setopt so that the isset() in the third hunk inverts sense? Of course if that IS possible, then the ultimate effect might be the expected one, and this point is moot. - Grepping Test/* doesn't find anything for SH_FILE_EXPANSION (in upper/lower, with/without underscores, etc.). Did I miss it? Does the test for the case in this thread belong in D04parameter or E01options? diff --git a/Src/subst.c b/Src/subst.c index 2d3eeb2..8c290cc 100644 --- a/Src/subst.c +++ b/Src/subst.c @@ -106,15 +106,20 @@ prefork(LinkList list, int flags, int *ret_flags) ret_flags = &ret_flags_local; /* will be discarded */ queue_signals(); - for (node = firstnode(list); node; incnode(node)) { + node = firstnode(list); + while (node) { + LinkNode nextnode = 0; if ((flags & (PREFORK_SINGLE|PREFORK_ASSIGN)) == PREFORK_ASSIGN && (insnode = keyvalpairelement(list, node))) { node = insnode; + incnode(node); *ret_flags |= PREFORK_KEY_VALUE; continue; } - if (errflag) + if (errflag) { + unqueue_signals(); return; + } if (isset(SHFILEEXPANSION)) { /* * Here and below we avoid taking the address @@ -132,6 +137,12 @@ prefork(LinkList list, int flags, int *ret_flags) * testing if cptr changed... */ setdata(node, cptr); + /* + * Advance now because we must not expand filenames again + * after string substitution (which may insert new nodes). + */ + nextnode = node; + incnode(nextnode); } if (!(node = stringsubst(list, node, flags & ~(PREFORK_TYPESET|PREFORK_ASSIGN), @@ -139,6 +150,10 @@ prefork(LinkList list, int flags, int *ret_flags) unqueue_signals(); return; } + if (isset(SHFILEEXPANSION)) + node = nextnode; + else + incnode(node); } for (node = firstnode(list); node; incnode(node)) { if (node == stop)