Bug in _path_files?

Bug in _path_files?

[Danek Duvall]

I have strange behavior in zsh 4.0.3 when completing directories in the
stack:

    % cd /usr/share/zsh; cd 4.0.3; cd functions
    % dirs -v
    0       /usr/share/zsh/4.0.3/functions
    1       /usr/share/zsh/4.0.3
    2       /usr/share/zsh
    3       ~
    % cd ~-2/^D
    4.0.1-pre-2/    4.0.3/     site-functions/
    % cd ~+2/^D
    functions/
    % cd ~2/^D
    functions/

The third form is the one I use all the time, but it seems to be wrong
here (it should have the output of the first form).  I do have
pushdminus set, but it shouldn't make a difference, although it does.

The following patch fixes my symptoms and is correct as far as I can see
it.  The idea being that without the +/-, you should jump directly to
the entry in $dirstack, rather than counting from one end or the other,
regardless of the value of pushdminus.

    --- _path_files-4.0.3	Wed Oct 24 12:31:52 2001
    +++ _path_files	Thu May  2 12:01:46 2002
    @@ -233,7 +233,7 @@
         else
           tmp1=$tmp1[2,-1]
         fi
    -    [[ -o pushdminus ]] && tmp1=$(( $#dirstack - $tmp1 ))
    +    [[ -o pushdminus && "$linepath" == [-+]* ]] && tmp1=$(( $#dirstack - $tmp1 ))
         if (( ! tmp1 )); then
           realpath=$PWD/
         elif [[ tmp1 -le $#dirstack ]]; then

Thanks,
Danek

Re: Bug in _path_files?

[Oliver Kiddle]

On Thu, May 02, 2002 at 12:13:19PM -0700, Danek Duvall wrote:

>     % cd ~2/^D
>     functions/
> 
> The third form is the one I use all the time, but it seems to be wrong
> here (it should have the output of the first form).  I do have
> pushdminus set, but it shouldn't make a difference, although it does.

You're right here. It seems to handle pushdminus for that third
form yet that form should not be affected by pushdminus. 

> The following patch fixes my symptoms and is correct as far as I can see
> it.  The idea being that without the +/-, you should jump directly to

The patch looks correct to me. However, it leaves some code that I
believe to be redundant (prepending `-' or `+' to $tmp1 only to
ignore it by using $tmp1[2,-1]) so I suggest the following patch
instead which I think makes the code a bit simpler (hopefully
without breaking it).

Thanks for the bug report

Oliver

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.15
diff -u -r1.15 _path_files
--- Completion/Unix/Type/_path_files	16 Apr 2002 08:27:47 -0000	1.15
+++ Completion/Unix/Type/_path_files	3 May 2002 10:41:44 -0000
@@ -224,20 +224,15 @@
     realpath="${HOME%/}/"
   elif [[ "$linepath" = ([-+]|)[0-9]## ]]; then
     if [[ "$linepath" != [-+]* ]]; then
-      if [[ -o pushdminus ]]; then
-        tmp1="-$linepath"
-      else
-        tmp1="+$linepath"
-      fi
-    else
       tmp1="$linepath"
-    fi
-    if [[ "$linepath" = -* ]]; then
-      tmp1=$(( $#dirstack $tmp1 ))
     else
-      tmp1=$tmp1[2,-1]
+      if [[ "$linepath" = -* ]]; then
+        tmp1=$(( $#dirstack $linepath ))
+      else
+        tmp1=$linepath[2,-1]
+      fi
+      [[ -o pushdminus ]] && tmp1=$(( $#dirstack - $tmp1 ))
     fi
-    [[ -o pushdminus ]] && tmp1=$(( $#dirstack - $tmp1 ))
     if (( ! tmp1 )); then
       realpath=$PWD/
     elif [[ tmp1 -le $#dirstack ]]; then

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: Bug in _path_files?

[Danek Duvall]

On Fri, May 03, 2002 at 11:52:00AM +0100, Oliver Kiddle wrote:

> The patch looks correct to me. However, it leaves some code that I
> believe to be redundant so I suggest the following patch instead which
> I think makes the code a bit simpler (hopefully without breaking it).

I was going for the least-change solution, but this is better, looks
correct, and works where I need it to.

Thanks!

Danek