From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1378 invoked by alias); 15 May 2011 10:12:23 -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: 29297 Received: (qmail 12405 invoked from network); 15 May 2011 10:12:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.220.171 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BmLFqYTxE7XhpYuwDCRmvQTbgbovVuECMQ97VxKRWkA=; b=DQMKN5iSdvDdFOGqI/ZXpH2+nFY3dHS/TW0iIz7ENf25J0Si3LXjDASoLhUr01ZFPV ElyhKjbVFr+1TcCkU3nKnVrx7Q0rhiZulgkEqyDIXI8ua7eBMgRi4d36WnkSBzGM0ZyT g4yd0y62d29QQ+AwXqqWICrsCgnFPd+O2COjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ws+napYqkfi/cTuvtkkq3hnNah9H1Mcvt2jBFv7rcNyajMqtEEvpVz4skuBTWCc+la foWhtsR1hvoVaDBLaHGarKAV7nDD12h2nvcJt0mSjPdACg0Q0cbGXvUn4wbYNosZieOS bTOVR3Vkz91BNjRWOzp5h0GSjf4AIzsK6FQcU= MIME-Version: 1.0 In-Reply-To: <110514183850.ZM15129@torch.brasslantern.com> References: <20110513191710.657d2f61@pws-pc.ntlworld.com> <20110513195324.6ab90eb2@pws-pc.ntlworld.com> <110513225805.ZM13712@torch.brasslantern.com> <110514183850.ZM15129@torch.brasslantern.com> Date: Sun, 15 May 2011 12:12:05 +0200 Message-ID: Subject: Re: PATCH Re: squeeze-slashes false not working? From: Mikael Magnusson To: Bart Schaefer Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On 15 May 2011 03:38, Bart Schaefer wrote: > On May 14, 8:45pm, Mikael Magnusson wrote: > } Subject: Re: PATCH Re: squeeze-slashes false not working? > } > } Okay, lucky for me it was the third zstyle from the top, > } zstyle ':completion:*' accept-exact-dirs 'yes' > } > } I do still want this set, but maybe it can be made not to consider the > } empty string an exact dir? > } This seems to do it, but I've no idea if it's sane. Sane is a strange > } word to use in _path_files though. > > This change doesn't fix it for me. If I apply your patch and then set > accept-exact-dirs yes, then //// completes things in the root between > the first and second slashes, but I'm back to /home/// being treated > as /home/. There must be something else going on. No idea what then. With /// (//// takes a bit too long), I get all sorts of stuff completed, dev/disk/by-label/, proc/sys/debug/ etc. > As an additional observation, even without your patch if I do this: > > % mkdir /tmp/ff /tmp/ffzz > % ls //ff/ > > I get silent failure. It completes /tmp if either I leave off the > trailing slash, or if there is at least one file in one of the > directories. I can't tell if this is the expected behavior or not. It acts the same way for me, but ls /tmp/ff/ with no files there also says ---- no match for: `arg', `directories', `file', or `corrections' so I don't think it's because of squeezing or path-completion. Same with accept-exact-dirs off. It seems logical that if the final result isn't accepted when typed explicitly, it isn't produced from a partial match either. > I suspect that we're also going to run into madness with filesystems > where "//" designates a network root or similar. There's the preserve-prefix style. With it set to //, ls /// acts the same as ls // without it set. So that's something at least. > Incidentally with the squeeze-slashes false + path-completion true > default behavior repaired, something like this: > > % ls ////////// > > Goes off on a merry lark finding all nine-element paths reachable from > the root and checking to see if they contain at least one file. This > may go wandering happily through networked filesystems and other roads > less traveled by, leaving the shell preoccupied and unresponsive for > long stretches. Yeah, emulating 'locate' extremely badly isn't my primary use-case :). You can say the same thing for /**/ too. (Though this seems to behave as a single * in my zshrc, but does hang for a long time from zsh -f + compinit, another mystery). > We might want to consider changing squeeze-slashes to default to true, > given that the shell has been inadvertently behaving that way for quite > some time now. -- Mikael Magnusson