Re: PATCH (?) Re: strange completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 2,  7:13am, Bart Schaefer wrote:
}
} I'm not sure whether the following is the correct fix, or whether that
} entire if/elif/else cascade should be wrapped in
} 
}     if [[ -n "$fake" ]]; then

That last idea is definitely wrong, at the least the "else" branch needs
to be taken, but this --

} +    if [[ "$tpre$tsuf" = */* && -n "$fake" ]]; then

-- is also too much.  It's OK for $fake to be empty as long as there is
something after the final slash in "$tpre$tsuf".

I was mildly surprised to discover that in [[ ... && ... ]] the stuff
to the left of the && is evaluated before expanding variables in the
stuff to the right of the &&.  The question for the patch below is,
in [[ foo/bar/ = (#b)*/(*) ]] is $match[1] guaranteed to be empty?
Or do I need ([^/]#) to be safe?

And jeez, somebody really needs to document compfiles *somewhere*.  I
recall we didn't want it detailed in the man page doc for some reason,
but ...


Index: Completion/Unix/Type/_path_files
===================================================================
--- Completion/Unix/Type/_path_files	1 Jun 2011 06:39:59 -0000
+++ Completion/Unix/Type/_path_files	3 Jun 2011 08:12:48 -0000
@@ -438,7 +438,7 @@
 
     tmp2=( "$tmp1[@]" )
 
-    if [[ "$tpre$tsuf" = */* ]]; then
+    if [[ "$tpre$tsuf" = (#b)*/(*) && -n "$fake${match[1]}" ]]; then
       compfiles -P$cfopt tmp1 accex "$skipped" "$_matcher $matcher[2]" "$sdirs" fake
     elif [[ "$sopt" = *[/f]* ]]; then
       compfiles -p$cfopt tmp1 accex "$skipped" "$_matcher $matcher[2]" "$sdirs" fake "$pats[@]"