Zsh autocompletion with no access to a parent directory

Zsh autocompletion with no access to a parent directory

[Matt Wright]

Hey,

I've run into a problem with autocompletion and I can't seem to find anything about it from googling. Hopefully someone might be able to help.

The situation is this: At work we make fairly heavy use of network home directories. In one particular case some important scripts live in ~foo/bin, however, the actually home directory of ~foo is not accessible. This appears to give _path_files a big headache, as trying to type the following results in no completion suggestions.

# ~foo/bin/<TAB>

As far as I can tell from my attempts to parse the debugging output, it is attempting to traverse ~foo for path expansion? I was attempting to look for a way to disable path expansion (the /u/l/b -> /usr/local/bin stuff) while leaving normal filename suggestion intact. Either that, or a way to alter _path_files such that it doesn't die in this situation.

Any ideas?

Regards,

Matt

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

On Tue, 13 Apr 2010 09:33:15 -0700
Matt Wright <matt@sysctl.co.uk> wrote:
> The situation is this: At work we make fairly heavy use of network home
> directories. In one particular case some important scripts live in
> ~foo/bin, however, the actually home directory of ~foo is not
> accessible. This appears to give _path_files a big headache, as trying to
> type the following results in no completion suggestions.
> 
> # ~foo/bin/<TAB>
> 
> As far as I can tell from my attempts to parse the debugging output, it
> is attempting to traverse ~foo for path expansion? I was attempting to look
> for a way to disable path expansion (the /u/l/b -> /usr/local/bin stuff)
> while leaving normal filename suggestion intact. Either that, or a way to
> alter _path_files such that it doesn't die in this situation.

You can try telling completion to accept any directory that it knows exists
without trying to expand the path:

zstyle ':completion:*' accept-exact-dirs true

I'm not sure if this will help in the case you're describing, however,
since it looks like it might not be able to tell if the directory exists.
You'll need zsh 4.3.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> zstyle ':completion:*' accept-exact-dirs true

Yep, sadly this doesn't work. 

> I'm not sure if this will help in the case you're describing, however,
> since it looks like it might not be able to tell if the directory exists.
> You'll need zsh 4.3.

zsh 4.3.9

I found something along the following lines:

zstyle -e ':completion:*' file-patterns '[[ $PREFIX == /expanded/path/to/network/[^/]# ]] && { setopt noglob; reply=(*(@)); setopt glob }'

That doesn't appear to do anything interesting though. I suspect I'm barking up the wrong tree with that one?

M

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> You can try telling completion to accept any directory that it knows exists
> without trying to expand the path:
> 
> zstyle ':completion:*' accept-exact-dirs true
> 
> I'm not sure if this will help in the case you're describing, however,
> since it looks like it might not be able to tell if the directory exists.
> You'll need zsh 4.3.

Another thought, is it possible to get it to /never/ expand directories. I almost (read. only by accident) never specify a directory below where the cursor is with an incomplete name. It seems wasteful and slow for autocompletion to go ferreting around network volumes looking for alternatives. Especially in an automount environment where such traversal could cause additional wait time whilst mounting other volumes?

M

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

Matt Wright wrote:
> > You can try telling completion to accept any directory that it knows exis=
> ts
> > without trying to expand the path:
> >=20
> > zstyle ':completion:*' accept-exact-dirs true
> >=20
> > I'm not sure if this will help in the case you're describing, however,
> > since it looks like it might not be able to tell if the directory exists.
> > You'll need zsh 4.3.
> 
> Another thought, is it possible to get it to /never/ expand directories.

(i.e. directories up to the / before the cursor).  That would make
perfect sense as an option, but unfortunately the file completion code
lives in one of the ditches in the eighth circle of hell ("Malecompo",
or something like that), and we're worried we won't be able to get back
from there.  However, you might have imagined that it wouldn't be too
difficult to extend accept-exact-dirs, which in turn wasn't so difficult
to add.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

Peter Stephenson wrote:
> Matt Wright wrote:
> > Another thought, is it possible to get it to /never/ expand directories.
> 
> (i.e. directories up to the / before the cursor).
>...
> you might have imagined that it wouldn't be too
> difficult to extend accept-exact-dirs, which in turn wasn't so difficult
> to add.

Well, it seems to work...  as well as checking this does what I think it
should, it would be good if anyone trying this out could ensure it
corresponds to the documentation, too.  There is at least a reasonable
chance it hasn't broken existing behaviour.

Note I called the style path-completion because expansion is a
completely different activity in zsh terms, and that it's assumed to be
true if you don't set it to get the current behaviour.

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.49
diff -p -u -r1.49 _path_files
--- Completion/Unix/Type/_path_files	14 Sep 2009 08:40:49 -0000	1.49
+++ Completion/Unix/Type/_path_files	14 Apr 2010 09:44:22 -0000
@@ -32,6 +32,7 @@ local tmp1 tmp2 tmp3 tmp4 i orig eorig p
 local pats haspats ignore pfx pfxsfx sopt gopt opt sdirs ignpar cfopt listsfx
 local nm=$compstate[nmatches] menu matcher mopts sort mid accex fake
 local listfiles listopts tmpdisp origtmp1 Uopt
+local accept_exact_dirs path_completion
 integer npathcheck
 local -a Mopts
 
@@ -191,6 +192,11 @@ zstyle -a ":completion:${curcontext}:" f
 
 zstyle -s ":completion:${curcontext}:" ignore-parents ignpar
 
+zstyle -t ":completion:${curcontext}:paths" accept-exact-dirs &&
+  accept_exact_dirs=1
+zstyle -T ":completion:${curcontext}:paths" path-completion &&
+  path_completion=1
+
 if [[ -n "$compstate[pattern_match]" ]]; then
   if { [[ -z "$SUFFIX" ]] && _have_glob_qual "$PREFIX" complete } ||
     _have_glob_qual "$SUFFIX" complete; then
@@ -350,16 +356,17 @@ for prepath in "$prepaths[@]"; do
   skipped=
   cpre=
 
-  if zstyle -t ":completion:${curcontext}:paths" accept-exact-dirs &&
-    [[ $pre = (#b)(*)/([^/]#) ]]; then
-    # We've been told that we can accept an exact directory
-    # prefix immediately.  Try this with the longest path prefix
-    # first:  this saves stats in the simple case and may get around
-    # automount behaviour if early components don't yet exist.
+  if [[ ( -n $accept_exact_dirs || -z $path_completion ) && \
+        $pre = (#b)(*)/([^/]#) ]]; then
+    # We've been told either that we can accept an exact directory prefix
+    # immediately, or that path expansion is inhibited.  Try the longest
+    # path prefix first: in the first case, this saves stats in the simple
+    # case and may get around automount behaviour if early components don't
+    # yet exist, and in the second case this is the prefix we want to keep.
     tmp1=$match[1]
     tpre=$match[2]
     while true; do
-      if [[ -d $prepath$realpath$donepath$tmp1 ]]; then
+      if [[ -z $path_completion || -d $prepath$realpath$donepath$tmp1 ]]; then
 	donepath=$donepath$tmp1/
 	pre=$tpre
 	break
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.226
diff -p -u -r1.226 compsys.yo
--- Doc/Zsh/compsys.yo	17 Feb 2010 06:16:31 -0000	1.226
+++ Doc/Zsh/compsys.yo	14 Apr 2010 09:44:23 -0000
@@ -1123,6 +1123,9 @@ When this style is true, any prefix of a
 directory is accepted without any attempt to complete it further.
 Hence, in the given example, the path tt(/usr/bin/) is accepted
 immediately and completion tried in that directory.
+
+If you wish to inhibit this behaviour entirely, set the tt(path-completion)
+style (see below) to tt(false).
 )
 kindex(add-space, completion style)
 item(tt(add-space))(
@@ -2259,6 +2262,20 @@ containing color names in the format of 
 the style is not set but this file is found in one of various standard
 locations it will be used as the default.
 )
+item(tt(path-completion))(
+This is used by filename completion.  By default, filename completion
+examines all components of a path to see if there are completions of
+that component.  For example, tt(/u/b/z) can be completed to
+tt(/usr/bin/zsh).  Explicitly setting this style to tt(false) inhibits this
+behaviour for path components before the cursorl; this overrides the
+setting of tt(accept-exact-dirs).
+
+Even with the style set to tt(false), it is still possible to complete
+multiple paths by setting the option tt(COMPLETE_IN_WORD) and moving the
+cursor back to the first component in the path to be completed.  For
+example, tt(/u/b/z) can be completed to tt(/usr/bin/zsh) if the cursor is
+after the tt(/u).
+)
 kindex(pine-directory, completion style)
 item(tt(pine-directory))(
 If set, specifies the directory containing PINE mailbox files.  There

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

On Wed, 14 Apr 2010 10:47:47 +0100
Peter Stephenson <pws@csr.com> wrote:
>... Explicitly setting this style to tt(false) inhibits this
> +behaviour for path components before the cursorl; this overrides the
> +setting of tt(accept-exact-dirs).

I've now rephrased this as:

Explicitly setting this style to tt(false) inhibits this
behaviour for path components up to the tt(/) before the cursor; this
overrides the setting of tt(accept-exact-dirs).

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

On Apr 14, 2010, at 3:01 AM, Peter Stephenson wrote:

> On Wed, 14 Apr 2010 10:47:47 +0100
> Peter Stephenson <pws@csr.com> wrote:
>> ... Explicitly setting this style to tt(false) inhibits this
>> +behaviour for path components before the cursorl; this overrides the
>> +setting of tt(accept-exact-dirs).

Thank you, thank you, thank you, thank you. That makes life so much nicer for me. Have just pulled those changes into my local dotfiles so they don't disappear when I reinstall my base system.

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> Note I called the style path-completion because expansion is a
> completely different activity in zsh terms, and that it's assumed to be
> true if you don't set it to get the current behaviour.

I've been meaning to reply for a week now, I did find a bug which is vaguely annoying. However, I'd been meaning to sit down and try and work it out myself. If I disable path-completion it does fix the original problem but it also produces a new one.

If you have a path with a "special" character in it, where by special so far I've found space and tilde, then completion stops offering results after that letter. It's particularly frustrating on a Mac, where many app bundles have spaces in their names but the actual executables are another two layers of directories deeper after the bundle name.

Also, we happen to have scripts at work that output directories with ~ in them (don't ask me why, I've no idea).

Any ideas?

Matt

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

On Fri, 23 Apr 2010 08:01:53 -0700
Matt Wright <matt@sysctl.co.uk> wrote:
> If you have a path with a "special" character in it, where by special
> so far I've found space and tilde, then completion stops offering
> results after that letter. It's particularly frustrating on a Mac, where
> many app bundles have spaces in their names but the actual executables
> are another two layers of directories deeper after the bundle name.

It appears to be this, though I haven't looked too closely since I've
heard it makes you blind.  Where is the input supposed to be unquoted?
Er... 

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.50
diff -p -u -r1.50 _path_files
--- Completion/Unix/Type/_path_files	14 Apr 2010 09:57:47 -0000	1.50
+++ Completion/Unix/Type/_path_files	23 Apr 2010 21:43:14 -0000
@@ -363,8 +363,8 @@ for prepath in "$prepaths[@]"; do
     # path prefix first: in the first case, this saves stats in the simple
     # case and may get around automount behaviour if early components don't
     # yet exist, and in the second case this is the prefix we want to keep.
-    tmp1=$match[1]
-    tpre=$match[2]
+    tmp1=${(Q)match[1]}
+    tpre=${(Q)match[2]}
     while true; do
       if [[ -z $path_completion || -d $prepath$realpath$donepath$tmp1 ]]; then
 	donepath=$donepath$tmp1/


-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

More from the world of "The Hairiest Shell Function in History, No,
Really, I Mean, Like, Ever".

On Fri, 23 Apr 2010 22:44:28 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Fri, 23 Apr 2010 08:01:53 -0700
> Matt Wright <matt@sysctl.co.uk> wrote:
> > If you have a path with a "special" character in it, where by special
> > so far I've found space and tilde, then completion stops offering
> > results after that letter. It's particularly frustrating on a Mac, where
> > many app bundles have spaces in their names but the actual executables
> > are another two layers of directories deeper after the bundle name.
> 
> It appears to be this, though I haven't looked too closely since I've
> heard it makes you blind.  Where is the input supposed to be unquoted?
> Er... 

Well, the input is supposed to be unquoted in two stages.  Or something.
I ran across this trying to complete the Calibre user guide,

/home/pws/ebooks/John Schember/Calibre Quick Start Guide (1)/Calibre Quick Start Guide - John Schember.epub

with accept-exact-dirs set.  That has the added interest over setting
path-completion to false that you then need a completely unquoted string
to test as a directory, and the added gotcha that if that doesn't work
it just blithely carries on doing normal completion so it doesn't
exercise the logic to put the directory onto the path immediately.

I tried this with files in directories called

(1)
[1]
{1}
1~1
1 1

just to be sure.

Matt, could you make sure this doesn't break anything?  Of course, with
code this trivial it's hard to make a mistake.  Sob.

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.51
diff -p -u -r1.51 _path_files
--- Completion/Unix/Type/_path_files	23 Apr 2010 21:52:00 -0000	1.51
+++ Completion/Unix/Type/_path_files	29 Apr 2010 21:27:45 -0000
@@ -357,16 +357,26 @@ for prepath in "$prepaths[@]"; do
   cpre=
 
   if [[ ( -n $accept_exact_dirs || -z $path_completion ) && \
-        ${(Q)pre} = (#b)(*)/([^/]#) ]]; then
+        ${pre} = (#b)(*)/([^/]#) ]]; then
     # We've been told either that we can accept an exact directory prefix
     # immediately, or that path expansion is inhibited.  Try the longest
     # path prefix first: in the first case, this saves stats in the simple
     # case and may get around automount behaviour if early components don't
     # yet exist, and in the second case this is the prefix we want to keep.
-    tmp1=$match[1]
-    tpre=$match[2]
+    #
+    # Explanation of substitution: For tmp1 and tpre, which are used further
+    # on, we need to remove quotes from everything that's not a pattern
+    # character, because the code that does the file generation only
+    # strips qutoes from pattern characters (you know better than
+    # to ask why).  Because we need to test for a real directory,
+    # however, for tmp2 we unquote everything.
+    tmp1=${match[1]}
+    tpre=${match[2]}
+    tmp2=${(Q)tmp1}
+    tmp1=${tmp1//(#b)\\([^\\\]\[\^\~\(\)\#\*\?])/$match[1]}
+    tpre=${tpre//(#b)\\([^\\\]\[\^\~\(\)\#\*\?])/$match[1]}
     while true; do
-      if [[ -z $path_completion || -d $prepath$realpath$donepath$tmp1 ]]; then
+      if [[ -z $path_completion || -d $prepath$realpath$donepath$tmp2 ]]; then
 	donepath=$donepath$tmp1/
 	pre=$tpre
 	break
@@ -381,7 +391,14 @@ for prepath in "$prepaths[@]"; do
 
   tpre="$pre"
   tsuf="$suf"
-  testpath="$donepath"
+  # Now we strip quoting from pattern characters, too, because
+  # testpath is used as a literal string.  I suppose we could
+  # alternatively use ${~testpath} later.
+  #
+  # I'm not sure if donepath itself should be entirely unquoted at
+  # some point but probably not here, since we need the quoted pattern
+  # characters in tmp1 below (I think).
+  testpath="${donepath//(#b)\\([\\\]\[\^\~\(\)\#\*\?])/$match[1]}"
 
   tmp2="${(M)tpre##${~skips}}"
   tpre="${tpre#$tmp2}"

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> Matt, could you make sure this doesn't break anything?  Of course, with
> code this trivial it's hard to make a mistake.  Sob.

Tried to at work and git-apply hates the patch format. Not sure why. Also patch -p0 wouldn't apply it cleanly to the current top-of-git.

I can play around when I get home with applying the changes by hand, if you've got a .diff you can attach (to avoid copy/paste problems) or a git-format-patch style patch. Either would be appriciated.

M

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Thu, 29 Apr 2010 15:14:33 -0700
Matt Wright <matt@sysctl.co.uk> wrote:
> > Matt, could you make sure this doesn't break anything?  Of course,
> > with code this trivial it's hard to make a mistake.  Sob.
> 
> Tried to at work and git-apply hates the patch format. Not sure why.
> Also patch -p0 wouldn't apply it cleanly to the current top-of-git.

It should apply OK to what's in the archive (and does here), but I did
change the previous patch from what I gave you before, so it would be
problematic with anything not under revision control...

Here's a patch against what was in the archive before I started tinkering
with it so it should apply to something older, as well as the new
patch.

pws


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

[-- Attachment #2: path_files_against_old.dif --]
[-- Type: application/x-diff, Size: 2368 bytes --]

[-- Attachment #3: path_files_against_new.dif --]
[-- Type: application/x-diff, Size: 2561 bytes --]

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> Here's a patch against what was in the archive before I started tinkering
> with it so it should apply to something older, as well as the new
> patch.

The "new" patch applied fine, thanks. I've no idea why the previous diffs wouldn't. I'll let you know how it works out.

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

> It should apply OK to what's in the archive (and does here), but I did
> change the previous patch from what I gave you before, so it would be
> problematic with anything not under revision control...

Yep, so I've been using it since we last talked and its good. Specifically all the sillyness with ~ characters in filenames works fine.

I've got some other network-based auto completion thoughts but I'll start a new thread on them.

M

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

On Tue, 4 May 2010 21:55:06 -0700
Matt Wright <matt@sysctl.co.uk> wrote:
> Yep, so I've been using it since we last talked and its good.
> Specifically all the sillyness with ~ characters in filenames works
> fine.

Thanks, I've committed that.  Unfortunately I've also realised it's only
half done:  the problem occurs when doing accept-exact-dirs and the first
examined directory doesn't exist, then we are wrongly quoting donepath for
use the next time round the loop.  The good news is that (if I do this
properly) this shouldn't affect your case, with path-completion false,
because that's handled completely the first time through.  For later.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Matt Wright]

Apologies for necroing this thread but I've hit a snag with this stuff and I can't work out whats going on. I threw some debug in around the code you changed in _path_files but all the paths look sane. After that it barrels off down compfiles code and my brain leapt out my left armpit.

If I do the following, using the _path_files changes you supplied me long ago:

# mkdir -p /tmp/foo\~bar/test
# ls /tmp/foo~bar/te<TAB>

All I get is:

[caesium: ~]$ ls /tmp/foo~bar/te
No matches found for: `files'

If I back up and TAB at the end of "foo~bar", zsh changes my prompt to:

[caesium: ~]$ ls /tmp/foo\~bar/ 

After which, it carries on completing properly. There's also a case I have at work where pressing tab in a setup like this appears to expand the ~ to \~ and then copy the entire completion path again. Though I don't appear to be able to replicate it right now I'll give you the gist below incase it rings any bells.

# command /var/tmp/foo~quack/usr/lib/local/foo<tab>

This becomes:

# command /var/tmp/foo\~quack//var/tmp/foo~quack/usr/lib/local/foo

And things get very confused.

M

On Apr 30, 2010, at 1:32 AM, Peter Stephenson wrote:

> On Thu, 29 Apr 2010 15:14:33 -0700
> Matt Wright <matt@sysctl.co.uk> wrote:
>>> Matt, could you make sure this doesn't break anything?  Of course,
>>> with code this trivial it's hard to make a mistake.  Sob.
>> 
>> Tried to at work and git-apply hates the patch format. Not sure why.
>> Also patch -p0 wouldn't apply it cleanly to the current top-of-git.
> 
> It should apply OK to what's in the archive (and does here), but I did
> change the previous patch from what I gave you before, so it would be
> problematic with anything not under revision control...
> 
> Here's a patch against what was in the archive before I started tinkering
> with it so it should apply to something older, as well as the new
> patch.
> 
> pws
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> <path_files_against_old.dif><path_files_against_new.dif>

Re: Zsh autocompletion with no access to a parent directory

[Peter Stephenson]

On Thu, 29 Jul 2010 08:46:47 -0700
Matt Wright <matt@sysctl.co.uk> wrote:
> Apologies for necroing this thread but I've hit a snag with this
> stuff and I can't work out whats going on. I threw some debug in
> around the code you changed in _path_files but all the paths look
> sane. After that it barrels off down compfiles code and my brain
> leapt out my left armpit.
> 
> If I do the following, using the _path_files changes you supplied me
> long ago:
> 
> # mkdir -p /tmp/foo\~bar/test
> # ls /tmp/foo~bar/te<TAB>
> 
> All I get is:
> 
> [caesium: ~]$ ls /tmp/foo~bar/te
> No matches found for: `files'
> 
> If I back up and TAB at the end of "foo~bar", zsh changes my prompt
> to:
> 
> [caesium: ~]$ ls /tmp/foo\~bar/ 

Er, I think you'll find it's all completely, er... anyway, I've run out of
armpits.

I think the following might be better (patch against the version in the
archive).  There's still one oddity where /tmp/foo~bar/te completes to
/tmp/foo\~bar/test but doesn't get recognised as a directory until you hit
tab again.  I think that's due to code down later on: probably because it's
found that the result doesn't match what was on the command line so refuses
to look and see if it's a directory.  I can't see where that's happening
but I think within compadd or compresult.

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.52
diff -p -u -r1.52 _path_files
--- Completion/Unix/Type/_path_files	5 May 2010 09:54:38 -0000	1.52
+++ Completion/Unix/Type/_path_files	3 Aug 2010 12:52:01 -0000
@@ -367,17 +367,24 @@ for prepath in "$prepaths[@]"; do
     # Explanation of substitution: For tmp1 and tpre, which are used further
     # on, we need to remove quotes from everything that's not a pattern
     # character, because the code that does the file generation only
-    # strips qutoes from pattern characters (you know better than
+    # strips quotes from pattern characters (you know better than
     # to ask why).  Because we need to test for a real directory,
     # however, for tmp2 we unquote everything.
     tmp1=${match[1]}
     tpre=${match[2]}
     tmp2=${(Q)tmp1}
-    tmp1=${tmp1//(#b)\\([^\\\]\[\^\~\(\)\#\*\?])/$match[1]}
+    tmp1=${tmp1//(#b)\\(?)/$match[1]}
     tpre=${tpre//(#b)\\([^\\\]\[\^\~\(\)\#\*\?])/$match[1]}
+    # Theory: donepath needs the quoting of special characters
+    # still in it.  However, we need it without at this point.
+    # (I think.)  Note this is different from the above where we're
+    # doing something a bit different.
+    tmp3=${donepath//(#b)\\(?)/$match[1]}
     while true; do
-      if [[ -z $path_completion || -d $prepath$realpath$donepath$tmp2 ]]; then
-	donepath=$donepath$tmp1/
+      if [[ -z $path_completion || -d $prepath$realpath$tmp3$tmp2 ]]; then
+	tmp3=$tmp3$tmp1/
+	# Now put donepath back the way it should be.  (I think.)
+	donepath=${tmp3//(#b)([\\\]\[\^\~\(\)\#\*\?])/\\$match[1]}
 	pre=$tpre
 	break
       elif [[ $tmp1 = (#b)(*)/([^/]#) ]]; then

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Zsh autocompletion with no access to a parent directory

[Bart Schaefer]

On Thu, Apr 29, 2010 at 2:38 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> More from the world of "The Hairiest Shell Function in History, No,
> Really, I Mean, Like, Ever".

Yeah, I keep wondering if it's not way hairier than even necessary, as
a side-effect of having been evolved out of predecessors each of which
was slightly hairier than the one before.

> Well, the input is supposed to be unquoted in two stages.  Or something.
> I ran across this trying to complete [...]
> with accept-exact-dirs set.  That has the added interest over setting
> path-completion to false that you then need a completely unquoted string
> to test as a directory, and the added gotcha that if that doesn't work
> it just blithely carries on doing normal completion so it doesn't
> exercise the logic to put the directory onto the path immediately.

This jibes [*] with my recollection of previous forays into this
swamp, although I never made it as far as discovering that a second
differently-(un)quoted variant of the value in tmp1 was necessary to
press on to the next patch of firm ground.

[*] No, it does not "jive."

> Of course, with code this trivial it's hard to make a mistake.  Sob.

If it were all trivial we'd never have any fun.

Re: Zsh autocompletion with no access to a parent directory

[Yves Frederix]

Hi all,

I have recently switched from bash to zsh and I am loving it. However,
there are still issues I didn't experience with bash. One of them is
the fact that tabcompletion was not able to cross unreadable parent
directories. With the solution proposed in this thread, this now works
more or less, but not completely... The problem seems to be related to
the use of ~user to access the homedirectory of 'user'.

A minimal example:
  testuser@dirac:~$ ls -ld Desktop/
  drwx--x--x 3 testuser testuser 4096 2010-06-25 09:33 Desktop/

  testuser@dirac:~$ ls -ld Desktop/work/
  drwxr-xr-x 2 testuser testuser 4096 2010-06-25 09:33 Desktop/work/

  testuser@dirac:~$ find Desktop/
  Desktop/
  Desktop/work
  Desktop/work/file2
  Desktop/work/file3
  Desktop/work/file4
  Desktop/work/file1

If I do (with accept-exact-dirs set to true):

  yves@dirac ~$ ls ~testuser/Desktop/work/<tab><tab>

nothing happens.

However, using the full path name:

  dirac ~$ ls /home/testuser/Desktop/work/<tab><tab>
  dirac ~$ ls /home/testuser/Desktop/work/file
  - files -
  file1  file2  file3  file4

So now it works. What could be going on here, and is there a way to
make the form with ~ work as well? Thanks!

Cheers,
YVES

On Tue, 13 Apr 2010 09:33:15 -0700
Matt Wright <matt@xxxxxxxxxxxx> wrote:
> The situation is this: At work we make fairly heavy use of network home
> directories. In one particular case some important scripts live in
> ~foo/bin, however, the actually home directory of ~foo is not
> accessible. This appears to give _path_files a big headache, as trying to
> type the following results in no completion suggestions.
>
> # ~foo/bin/<TAB>
>
> As far as I can tell from my attempts to parse the debugging output, it
> is attempting to traverse ~foo for path expansion? I was attempting to look
> for a way to disable path expansion (the /u/l/b -> /usr/local/bin stuff)
> while leaving normal filename suggestion intact. Either that, or a way to
> alter _path_files such that it doesn't die in this situation.

You can try telling completion to accept any directory that it knows exists
without trying to expand the path:

zstyle ':completion:*' accept-exact-dirs true

I'm not sure if this will help in the case you're describing, however,
since it looks like it might not be able to tell if the directory exists.
You'll need zsh 4.3.

-- 
Peter Stephenson <pws@xxxxxxx>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in
England and Wales, registered number 4187346, registered office
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4
0WZ, United Kingdom