Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson <mikachu@gmail.com>]

On 15 May 2011 03:38, Bart Schaefer <schaefer@brasslantern.com> 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/<TAB>
>
> 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/<tab> 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 ///<tab> acts
the same as ls //<tab> 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 //////////<TAB>
>
> 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 /**/<tab> 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