unzip and _path_files interaction

unzip and _path_files interaction

[Clint Adams]

Same error as with the previous _cvs problem.  To reproduce:

mkdir /tmp/uztest
cd /tmp/uztest
touch zip.zip
unzip <TAB>


Seems that the (z) in "${(@z)${(@M)tmp1:#-g*}#-g}" is turning
(#i)*.(zip|[jw]ar) into ( #i ) *.(zip|[jw]ar)

Re: unzip and _path_files interaction

[Sven Wischnowsky]

Clint Adams wrote:

> Same error as with the previous _cvs problem.  To reproduce:
> 
> mkdir /tmp/uztest
> cd /tmp/uztest
> touch zip.zip
> unzip <TAB>
> 
> 
> Seems that the (z) in "${(@z)${(@M)tmp1:#-g*}#-g}" is turning
> (#i)*.(zip|[jw]ar) into ( #i ) *.(zip|[jw]ar)

Hrm. I've got two patches now because I'm not sure where the bug
really is. It's all caused by the lexer treating parens in the first
word specially. The (z) modifier only calls the lexer as if the
parameter value were a complete command line and hence the result:

  % a='(#i)foo bar'
  % print -lr ${(z)a}
  (
  #i
  )
  foo
  bar
  % a='x (#i)foo bar'                                                            
  % print -lr ${(z)a}
  x
  (#i)foo
  bar

So, either we think that the (z) code should behave differently, then
we should use the first patch:

------------------------------------------------------------
diff -ur -r ../oz/Src/hist.c ./Src/hist.c
--- ../oz/Src/hist.c	Sun May 26 19:55:10 2002
+++ ./Src/hist.c	Tue May 28 21:31:56 2002
@@ -2221,7 +2221,7 @@
 {
     int num = 0, cur = -1, got = 0, ne = noerrs, ocs = cs, oll = ll;
     int owb = wb, owe = we, oadx = addedx, ozp = zleparse, onc = nocomments;
-    int ona = noaliases;
+    int ona = noaliases, ignore = 0;
     char *p;
 
     if (!list)
@@ -2234,13 +2234,16 @@
     if (buf) {
 	int l = strlen(buf);
 
-	p = (char *) zhalloc(l + 2);
-	memcpy(p, buf, l);
-	p[l] = ' ';
-	p[l + 1] = '\0';
+	p = (char *) zhalloc(l + 4);
+        p[0] = 'x';
+        p[1] = ' ';
+	memcpy(p + 2, buf, l);
+	p[l + 2] = ' ';
+	p[l + 3] = '\0';
 	inpush(p, 0, NULL);
-	cs = strlen(p) + 1;
+	cs = strlen(p) + 3;
 	nocomments = 1;
+        ignore = 1;
     } else if (!isfirstln && chline) {
 	p = (char *) zhalloc(hptr - chline + ll + 2);
 	memcpy(p, chline, hptr - chline);
@@ -2270,9 +2273,13 @@
 	if (tok == ENDINPUT || tok == LEXERR)
 	    break;
 	if (tokstr && *tokstr) {
-	    untokenize((p = dupstring(tokstr)));
-	    addlinknode(list, p);
-	    num++;
+            if (ignore)
+                ignore--;
+            else {
+                untokenize((p = dupstring(tokstr)));
+                addlinknode(list, p);
+                num++;
+            }
 	} else if (buf) {
 	    if (IS_REDIROP(tok) && tokfd >= 0) {
 		char b[20];
------------------------------------------------------------

Or we think that it's valuable to keep (z) parsing as if it were a
complete command line, then we should use the second patch:

------------------------------------------------------------
diff -ur -r ../oz/Completion/Unix/Type/_path_files ./Completion/Unix/Type/_path_files
--- ../oz/Completion/Unix/Type/_path_files	Sun May 26 19:55:12 2002
+++ ./Completion/Unix/Type/_path_files	Tue May 28 22:55:14 2002
@@ -23,9 +23,11 @@
 (( $tmp1[(I)-[/g]*] )) && haspats=yes
 (( $tmp1[(I)-g*] )) && gopt=yes
 if (( $tmp1[(I)-/] )); then
-  pats=( '*(-/)' ${(z)${(M)tmp1:#-g*}#-g} )
+  pats="${(@)${(@M)tmp1:#-g*}#-g}"
+  pats=( '*(-/)' ${${(z):-x $pats}[2,-1]} )
 else
-  pats=( "${(@z)${(@M)tmp1:#-g*}#-g}" )
+  pats="${(@)${(@M)tmp1:#-g*}#-g}"
+  pats=( ${${(z):-x $pats}[2,-1]} )
 fi
 pats=( "${(@)pats:# #}" )
 
------------------------------------------------------------

Or don't know. Help, anyone?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: unzip and _path_files interaction

[Bart Schaefer]

On Wed, 29 May 2002, Sven Wischnowsky wrote:

> > Seems that the (z) in "${(@z)${(@M)tmp1:#-g*}#-g}" is turning
> > (#i)*.(zip|[jw]ar) into ( #i ) *.(zip|[jw]ar)
>
> Hrm. I've got two patches now because I'm not sure where the bug
> really is. It's all caused by the lexer treating parens in the first
> word specially. The (z) modifier only calls the lexer as if the
> parameter value were a complete command line [...]
>
> So, either we think that the (z) code should behave differently, then
> we should use the first patch [...]
>
> Or we think that it's valuable to keep (z) parsing as if it were a
> complete command line, then we should use the second patch [...]
>
> Or don't know. Help, anyone?

I think (z) should keep working the way it does, or at least we need
somthing that does work the way it now does.  So for the time being I'd
go with the second patch.

Re: unzip and _path_files interaction

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I think (z) should keep working the way it does, or at least we need
> somthing that does work the way it now does.  So for the time being I'd
> go with the second patch.

I was feeling the same way...


Bye
  Sven

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.17
diff -u -r1.17 _path_files
--- Completion/Unix/Type/_path_files	21 May 2002 07:35:34 -0000	1.17
+++ Completion/Unix/Type/_path_files	29 May 2002 15:03:36 -0000
@@ -23,9 +23,11 @@
 (( $tmp1[(I)-[/g]*] )) && haspats=yes
 (( $tmp1[(I)-g*] )) && gopt=yes
 if (( $tmp1[(I)-/] )); then
-  pats=( '*(-/)' ${(z)${(M)tmp1:#-g*}#-g} )
+  pats="${(@)${(@M)tmp1:#-g*}#-g}"
+  pats=( '*(-/)' ${${(z):-x $pats}[2,-1]} )
 else
-  pats=( "${(@z)${(@M)tmp1:#-g*}#-g}" )
+  pats="${(@)${(@M)tmp1:#-g*}#-g}"
+  pats=( ${${(z):-x $pats}[2,-1]} )
 fi
 pats=( "${(@)pats:# #}" )
 

-- 
Sven Wischnowsky                          wischnow@berkom.de