Re: PATCH: Problem with _expand, _path_files, and $(command)

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jul 3, 10:12am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Problem with _expand, _path_files, and $(command)
> }
> } Bart Schaefer wrote:
> } 
> } > zagzig[88] echo $(exit 0)
> } > zagzig[88] echo \$\*\(exit\ 0Om\)
> } 
> } Shouldn't we just test for [[ $PREFIX$SUFFIX = *\$\(*\)* ]] and
> } give up if that is true?
> 
> This is a contrived example, but:
> 
> zagzig[128] ls Completion/$(echo Core)/_
> Completing file
> _funcall            _compalso           _files              _ignored          
> _menu               _approximate        _list               _setup
> (etc.)
> 
> This is without the _expand completer.  (The odd-looking order of the
> file names is because my styles display them sorted by mod time.)  Is
> that still going to work if _path_files gives up as you suggest?

Hm, no. Maybe just change the patterns in lines 120, 122, 166 and 168
from `(?*)' to `(*[^\$])'? (Haven't tried...)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Bart Schaefer]

On Jul 3, 11:01am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Problem with _expand, _path_files, and $(command)
}
} > } > zagzig[88] echo $(exit 0)
} > } > zagzig[88] echo \$\*\(exit\ 0Om\)
} 
} Maybe just change the patterns in lines 120, 122, 166 and 168
} from `(?*)' to `(*[^\$])'? (Haven't tried...)

Not quite; I also had to change the patterns on lines 153 and 154.

zagzig[95] echo $(exit 0)
No matches for `file' or `corrections'


Index: Completion/Core/_path_files
===================================================================
@@ -117,9 +117,9 @@
 
     tmp2=()
     for tmp1 in "$pats[@]"; do
-      if [[ "$tmp1" = (#b)(?*)(\(\([^\|~]##\)\)) ]]; then
+      if [[ "$tmp1" = (#b)(*[^\$])(\(\([^\|~]##\)\)) ]]; then
         tmp2=( "$tmp2[@]" "${match[1]}((${sort}${match[2][3,-1]}" )
-      elif [[ "$tmp1" = (#b)(?*)(\([^\|~]##\)) ]]; then
+      elif [[ "$tmp1" = (#b)(*[^\$])(\([^\|~]##\)) ]]; then
         tmp2=( "$tmp2[@]" "${match[1]}(${sort}${match[2][2,-1]}" )
       else
         tmp2=( "$tmp2[@]" "${tmp1}(${sort})" )
@@ -150,8 +150,8 @@
 zstyle -s ":completion:${curcontext}:files" ignore-parents ignpar
 
 if [[ -n "$compstate[pattern_match]" &&
-      ( ( -z "$SUFFIX" && "$PREFIX" = *\([^\|\~]##\) ) ||
-        "$SUFFIX" =  *\([^\|\~]##\) ) ]]; then
+      ( ( -z "$SUFFIX" && "$PREFIX" = (|*[^\$])\([^\|\~]##\) ) ||
+        "$SUFFIX" =  (|*[^\$])\([^\|\~]##\) ) ]]; then
   # Copy all glob qualifiers from the line to
   # the patterns used when generating matches
   if [[ "$SUFFIX" = *\([^\|\~]##\) ]]; then
@@ -163,9 +163,9 @@
   fi
   tmp2=()
   for tmp1 in "$pats[@]"; do
-    if [[ "$tmp1" = (#b)(?*)(\(\([^\|~]##\)\)) ]]; then
+    if [[ "$tmp1" = (#b)(*[^\$])(\(\([^\|~]##\)\)) ]]; then
       tmp2=( "$tmp2[@]" "${match[1]}((${tmp3}${match[2][3,-1]}" )
-    elif [[ "$tmp1" = (#b)(?*)(\([^\|~]##\)) ]]; then
+    elif [[ "$tmp1" = (#b)(*[^\$])(\([^\|~]##\)) ]]; then
       tmp2=( "$tmp2[@]" "${match[1]}(${tmp3}${match[2][2,-1]}" )
     else
       tmp2=( "$tmp2[@]" "${tmp1}(${tmp3})" )

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Sven Wischnowsky]

Bart Schaefer wrote:

> } I found another one: completion after something like `../$[4+]/'
> [...]
> } Blah. Very ugly. For now I had to add some $(print...)s, does anyone
> } see a better solution?
> 
> Yes:  Use `eval'.  `$(print -r ...)' won't do the right thing in the
> array context, will it?  For file names with embedded spaces, etc.?

Argh, right. I just couldn't think of...

> The one remaining problem is that zwarn() calls trashzle() even when
> stderr has been redirected away from the terminal.  Does anyone see a
> problem with the utils.c patch below?

...this. Looks sensible.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Bart Schaefer]

On Jul 4, 10:04am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Problem with _expand, _path_files, and $(command)
}
} Is the eval in line 324 [of _path_files] still needed?

It appears not.

} I found another one: completion after something like `../$[4+]/'
[...]
} Blah. Very ugly. For now I had to add some $(print...)s, does anyone
} see a better solution?

Yes:  Use `eval'.  `$(print -r ...)' won't do the right thing in the
array context, will it?  For file names with embedded spaces, etc.?

The one remaining problem is that zwarn() calls trashzle() even when
stderr has been redirected away from the terminal.  Does anyone see a
problem with the utils.c patch below?

Index: Completion/Core/_expand
===================================================================
@@ -61,9 +61,9 @@
    zstyle -T ":completion:${curcontext}:" substitute; then
   [[ ! -o ignorebraces && "${#${exp}//[^\{]}" = "${#${exp}//[^\}]}" ]] &&
       eval exp\=\( ${${(q)exp}:gs/\\{/\{/:gs/\\}/\}/} \)
-  exp=( $(print -r ${${(e)exp//\\[ 	
+  eval 'exp=( ${${(e)exp//\\[ 	
 ]/ }//(#b)([ 	
-])/\\$match[1]}) ) 2>/dev/null
+])/\\$match[1]} )' 2>/dev/null
 else
   exp=( ${exp:s/\\\$/\$} )
 fi
@@ -95,7 +95,7 @@
 
 zstyle -s ":completion:${curcontext}:" keep-prefix tmp || tmp=changed
 if [[ "$word" = [\~\$]*/* && "$tmp" = (yes|true|on|1|changed) ]]; then
-  epre=( $(print -r ${(e)~${word%%/*}}) ) 2>/dev/null
+  eval 'epre=( ${(e)~${word%%/*}} )' 2>/dev/null
   if [[ -n "$epre" && $#epre -eq 1 ]]; then
     opre="${word%%/*}"
     pre="$epre[1]"
Index: Completion/Core/_path_files
===================================================================
@@ -247,9 +247,10 @@
   # after the first slash after the parameter expansion.
   # This fails for things like `f/$foo/b/<TAB>' where the first `f' is
   # meant as a partial path.
+
   linepath="${(M)pre##*\$[^/]##/}"
-  realpath=$(print -r ${(e)~linepath}) 2>/dev/null
-    [[ -z "$realpath" || "$realpath" = "$linepath" ]] && return 1
+  eval 'realpath=${(e)~linepath}' 2>/dev/null
+  [[ -z "$realpath" || "$realpath" = "$linepath" ]] && return 1
   pre="${pre#${linepath}}"
   i="${#linepath//[^\\/]}"
   orig="${orig[1,(in:i:)/][1,-2]}"
@@ -321,7 +322,7 @@
     else
       compfiles -p$cfopt tmp1 accex "$skipped" "$_matcher" '' fake "$pats[@]"
     fi
-    eval 'tmp1=( $~tmp1 )' 2>/dev/null
+    tmp1=( $~tmp1 )
 
     if [[ -n "$PREFIX$SUFFIX" ]]; then
       # See which of them match what's on the line.
Index: Src/utils.c
===================================================================
@@ -67,7 +67,8 @@
 {
     if (errflag || noerrs)
 	return;
-    trashzle();
+    if (isatty(2))
+	trashzle();
     /*
      * scriptname is set when sourcing scripts, so that we get the
      * correct name instead of the generic name of whatever

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jul 3, 11:01am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Problem with _expand, _path_files, and $(command)
> }
> } > } > zagzig[88] echo $(exit 0)
> } > } > zagzig[88] echo \$\*\(exit\ 0Om\)
> } 
> } Maybe just change the patterns in lines 120, 122, 166 and 168
> } from `(?*)' to `(*[^\$])'? (Haven't tried...)
> 
> Not quite; I also had to change the patterns on lines 153 and 154.
> 
> zagzig[95] echo $(exit 0)
> No matches for `file' or `corrections'

Is the eval in line 324 still needed?


I found another one: completion after something like `../$[4+]/'
reported an error because it's a math error and math expressions are
parsed later (after paramsubst() has returned).

Blah. Very ugly. For now I had to add some $(print...)s, does anyone
see a better solution?

Bye
 Sven

Index: Completion/Core/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_expand,v
retrieving revision 1.24
diff -u -r1.24 _expand
--- Completion/Core/_expand	2000/07/02 17:21:54	1.24
+++ Completion/Core/_expand	2000/07/04 08:04:22
@@ -61,9 +61,9 @@
    zstyle -T ":completion:${curcontext}:" substitute; then
   [[ ! -o ignorebraces && "${#${exp}//[^\{]}" = "${#${exp}//[^\}]}" ]] &&
       eval exp\=\( ${${(q)exp}:gs/\\{/\{/:gs/\\}/\}/} \)
-  exp=( ${${(e)exp//\\[ 	
+  exp=( $(print -r ${${(e)exp//\\[ 	
 ]/ }//(#b)([ 	
-])/\\$match[1]} ) 2>/dev/null
+])/\\$match[1]}) ) 2>/dev/null
 else
   exp=( ${exp:s/\\\$/\$} )
 fi
@@ -95,7 +95,7 @@
 
 zstyle -s ":completion:${curcontext}:" keep-prefix tmp || tmp=changed
 if [[ "$word" = [\~\$]*/* && "$tmp" = (yes|true|on|1|changed) ]]; then
-  epre=( ${(e)~${word%%/*}} )
+  epre=( $(print -r ${(e)~${word%%/*}}) ) 2>/dev/null
   if [[ -n "$epre" && $#epre -eq 1 ]]; then
     opre="${word%%/*}"
     pre="$epre[1]"
Index: Completion/Core/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_path_files,v
retrieving revision 1.24
diff -u -r1.24 _path_files
--- Completion/Core/_path_files	2000/07/03 17:45:47	1.24
+++ Completion/Core/_path_files	2000/07/04 08:04:22
@@ -247,10 +247,9 @@
   # after the first slash after the parameter expansion.
   # This fails for things like `f/$foo/b/<TAB>' where the first `f' is
   # meant as a partial path.
-
   linepath="${(M)pre##*\$[^/]##/}"
-  realpath=${(e)~linepath}
-  [[ "$realpath" = "$linepath" ]] && return 1
+  realpath=$(print -r ${(e)~linepath}) 2>/dev/null
+    [[ -z "$realpath" || "$realpath" = "$linepath" ]] && return 1
   pre="${pre#${linepath}}"
   i="${#linepath//[^\\/]}"
   orig="${orig[1,(in:i:)/][1,-2]}"

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Bart Schaefer]

On Jul 3, 10:12am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Problem with _expand, _path_files, and $(command)
}
} Bart Schaefer wrote:
} 
} > zagzig[88] echo $(exit 0)
} > zagzig[88] echo \$\*\(exit\ 0Om\)
} 
} Shouldn't we just test for [[ $PREFIX$SUFFIX = *\$\(*\)* ]] and
} give up if that is true?

This is a contrived example, but:

zagzig[128] ls Completion/$(echo Core)/_
Completing file
_funcall            _compalso           _files              _ignored          
_menu               _approximate        _list               _setup
(etc.)

This is without the _expand completer.  (The odd-looking order of the
file names is because my styles display them sorted by mod time.)  Is
that still going to work if _path_files gives up as you suggest?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Problem with _expand, _path_files, and $(command)

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> After the patch below, there's still a problem with _path_files, because
> the parens in $(exit 0) are interpreted as enclosing a glob qualifier, so
> something else goes haywire:
> 
> zagzig[88] echo $(exit 0)
> zagzig[88] echo \$\*\(exit\ 0Om\)
> 
> ...
> 
> -    tmp1=( $~tmp1 )
> +    eval 'tmp1=( $~tmp1 )' 2>/dev/null

Hrm. I don't like that eval there, especially if it still doesn't
work. Shouldn't we just test for [[ $PREFIX$SUFFIX = *\$\(*\)* ]] and
give up if that is true?

Or am I missing something?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

PATCH: Problem with _expand, _path_files, and $(command)

[Bart Schaefer]

The first problem is that the stderr of the command messes up the display.
Then if the command doesn't produce any output, assorted bad things happen
at line 80 of _expand:

zagzig[120] echo $(stty -a)stty: standard input: Inappropriate ioctl for device

_expand:80: unknown file attribute
zagzig[121] echo $(exit 0)
_expand:80: missing end of string

Both of those examples break _complete_debug, because they're treated as
fatal errors (just like the problem we were having with ${(e)garbage} a
while ago).

If I remove _expand from the completer style, I get this:

zagzig[86] echo $(exit 0)
_path_files:325: missing end of string

After the patch below, there's still a problem with _path_files, because
the parens in $(exit 0) are interpreted as enclosing a glob qualifier, so
something else goes haywire:

zagzig[88] echo $(exit 0)
zagzig[88] echo \$\*\(exit\ 0Om\)

Of course the best thing to do at lines 64-66 of _expand, would be to
capture the standard error of the $(...) and use `_message -r' to display
it.  However, I can't think of any way to capture stderr that wouldn't
cause the entire exp=(...) to be forced into a subshell, except by using
a temp file, which is unacceptable overhead in the "normal" case.

--- zsh-forge/current/Completion/Core/_expand	Thu Jun 29 01:32:02 2000
+++ zsh-3.1.9/Completion/Core/_expand	Sun Jul  2 09:35:37 2000
@@ -63,7 +63,7 @@
       eval exp\=\( ${${(q)exp}:gs/\\{/\{/:gs/\\}/\}/} \)
   exp=( ${${(e)exp//\\[ 	
 ]/ }//(#b)([ 	
-])/\\$match[1]} )
+])/\\$match[1]} ) 2>/dev/null
 else
   exp=( ${exp:s/\\\$/\$} )
 fi
@@ -77,7 +77,7 @@
 # Now try globbing.
 
 [[ "$force" = *g* ]] || zstyle -T ":completion:${curcontext}:" glob &&
-    exp=( ${~exp} )
+    eval 'exp=( ${~exp} )' 2>/dev/null
 
 # If we don't have any expansions or only one and that is the same
 # as the original string, we let other completers run.
--- zsh-forge/current/Completion/Core/_path_files	Mon Jun 19 09:47:27 2000
+++ zsh-3.1.9/Completion/Core/_path_files	Sun Jul  2 09:29:39 2000
@@ -322,7 +322,7 @@
     else
       compfiles -p$cfopt tmp1 accex "$skipped" "$_matcher" '' fake "$pats[@]"
     fi
-    tmp1=( $~tmp1 )
+    eval 'tmp1=( $~tmp1 )' 2>/dev/null
 
     if [[ -n "$PREFIX$SUFFIX" ]]; then
       # See which of them match what's on the line.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net