From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28964 invoked by alias); 29 Aug 2016 19:31:03 -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: 39117 Received: (qmail 26776 invoked from network); 29 Aug 2016 19:31:03 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-7.server.virginmedia.net 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(80.0.253.71):SA:0(-0.0/5.0):. Processed in 0.53109 secs); 29 Aug 2016 19:31:03 -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=-0.0 required=5.0 tests=SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.71 as permitted sender) X-Originating-IP: [86.21.161.213] X-Spam: 0 X-Authority: v=2.1 cv=KKyndwxo c=1 sm=1 tr=0 a=oo3MgO7t/4XyXFuSzI3dDQ==:117 a=oo3MgO7t/4XyXFuSzI3dDQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=uS8d3DR3e-M41LeKvvcA:9 a=CjuIK1q_8ugA:10 a=z9dJwno5l634igLiVhy-:22 Date: Mon, 29 Aug 2016 20:30:51 +0100 From: Peter Stephenson To: Zsh hackers list Subject: Re: Broken specialsed file completion Message-ID: <20160829203051.04418a21@ntlworld.com> In-Reply-To: <160828190158.ZM23517@torch.brasslantern.com> References: <20160828222112.0433a930@ntlworld.com> <8760qkqz8l.fsf@ft.bewatermyfriend.org> <160828190158.ZM23517@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 28 Aug 2016 19:01:58 -0700 Bart Schaefer wrote: > The difference is this expression (_path_files line 59): > > sopt="-${(@j::M)${(@)tmp1#-}#?}" > > Previously this would result in sopt='-' but now it appears to yield > sopt='' -- which doesn't seem to make any sense, because the "-" is > outside of the parameter expansion. However, it's affected by the > setting of rcexpandparam in $_comp_options. > > The expansion of ${(@j::M)${(@)tmp1#-}#?} used to result in a scalar > empty string, but now it results in an empty array, and rcexpandparam > discards the "-" because it has no array element with which to pair. > > What's happened here is that given (@j::), the @ is forcing an array, > where previously the j would force a string. > > I'm still not entirely sure what it should mean to use @ and j in the > same ex/pansion, but clearly it's wrong for the j to be ignored. It certainly seems right @ shouldn't be preventing joining. There's also the question of whether it should force splitting later. Traditionally it hasn't, and I think that's correct, too. However, the latter isn't really relevant here, I suppose, as there'd be no split so the empty expression would stay a scalar if already joined. I'm not sure what the @ should be doing there, either, given that joining happens before any splitting, and hence also before considering multiple elements. I suspect it's got something to do with affecting the way the matching happens, but I'm not at all sure it actually does that. The use of it here is opaque enough that rewriting that expansion might be a good idea anyway; it's relying on an obscurely different set of behaviours if it is or isn't presented with an array. But how to rewrite it is another question. > Does the D04 test case below look correct to everyone? > + > + ( > + set -- "one two" "bucklemy shoe" > + IFS= > + setopt shwordsplit rcexpandparam > + print -l "X${(@j.-.)*}" > + ) > +0:Use of @ does not prevent forced join with j > +>Xone two-bucklemy shoe Yes, I think that's right. Thanks for working this out. pws