From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id e3aea106 for ; Wed, 27 Feb 2019 08:28:23 +0000 (UTC) Received: (qmail 6269 invoked by alias); 27 Feb 2019 08:28:08 -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: List-Unsubscribe: X-Seq: 44089 Received: (qmail 28493 invoked by uid 1010); 27 Feb 2019 08:28:08 -0000 X-Qmail-Scanner-Diagnostics: from granite.fifsource.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25370. spamassassin: 3.4.2. Clear:RC:0(173.255.216.206):SA:0(-1.9/5.0):. Processed in 3.48496 secs); 27 Feb 2019 08:28:08 -0000 X-Envelope-From: phil@fifi.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at fifi.org designates 173.255.216.206 as permitted sender) Message-ID: <20c973717ab6749fef5694b76a9f7b72a35ee72c.camel@fifi.org> Subject: Re: A cute bug involving aliases and _remote_files From: Philippe Troin To: Zsh hackers list Date: Wed, 27 Feb 2019 00:27:30 -0800 In-Reply-To: <3D38E0FC-DE43-4CFD-86E2-B258D9DA816C@dana.is> References: <0d066d726a76a85461089339e25e207663d389b7.camel@fifi.org> <3D38E0FC-DE43-4CFD-86E2-B258D9DA816C@dana.is> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 2019-02-26 at 03:23 -0600, dana wrote: > On 25 Feb 2019, at 20:49, Philippe Troin wrote: > > Would it make sense to use "command ls" instead of "ls" for remote > > directory listings in _remote_files? That would make sure that no > > aliases nor functions are involved. > > That *seems* reasonable...? > > Now that you mention it, GNU ls changed its default quoting behaviour somewhat > recently. I think it only quotes when (a) QUOTING_STYLE is set, (b) > one of the > quoting options is given on the command line, or (c) the output is a > TTY — so > it's unlikely to be an issue for _remote_files, given how it's > normally used. > But maybe it'd be a good idea to force it off anyway, just in case? I'm completely unaware of how QUOTING_STYLE could possibly be getting us into trouble, but the way you call the binary (variable=value command ls) is bourne-shell only (bash, sh, ash, ksh), and will not work if the remote system is using c-shells (csh, tcsh). I'd recommend using env, as in: + remfiles=(${(M)${(f)"$( + _call_program files $cmd $cmd_args $host \ + env QUOTING_STYLE=literal ls -d1FL -- "$rempat" > 2>/dev/null + )"}%%[^/]#(|/)}) That will work everywhere. Now, I haven't seen anyone using c-shells in a very long while, but I'm sure there are some holdouts :-) Since you use "env" instead of calling ls directory, you don't need command anymore, because no alias expansion will occur for ls. I assume we don't care about global aliases, which none of the proposed solutions would handle anyways. Phil. > diff --git a/Completion/Unix/Type/_remote_files > b/Completion/Unix/Type/_remote_files > index 267715a51..89cf102cf 100644 > --- a/Completion/Unix/Type/_remote_files > +++ b/Completion/Unix/Type/_remote_files > @@ -59,7 +59,10 @@ if zstyle -T ":completion:${curcontext}:files" > remote-access; then > fi > > # remote filenames > - remfiles=(${(M)${(f)"$(_call_program files $cmd $cmd_args $host ls > -d1FL -- "$rempat" 2>/dev/null)"}%%[^/]#(|/)}) > + remfiles=(${(M)${(f)"$( > + _call_program files $cmd $cmd_args $host \ > + QUOTING_STYLE=literal command ls -d1FL -- "$rempat" > 2>/dev/null > + )"}%%[^/]#(|/)}) > > compset -P '*/' > compset -S '/*' || (( ${args[(I)-/]} )) || suf='remote file' >