[stew@vireo.org: Bug#295511: patch]

[stew@vireo.org: Bug#295511: patch]

[Clint Adams]

Wayne, any thoughts?

----- Forwarded message from Mike O'Connor <stew@vireo.org> -----

Here is a patch that seems to fix this bug.  What I have done is to
alter the _make completion functions so that recursion in expanding
variables is limited to only going 10 levels deep.

-stew


diff -ru zsh-4.2.4/Completion/Unix/Command/_make zsh-4.2.4-makecompletionfix/Completion/Unix/Command/_make
--- zsh-4.2.4/Completion/Unix/Command/_make	2005-03-01 23:17:01.000000000 -0500
+++ zsh-4.2.4-makecompletionfix/Completion/Unix/Command/_make	2005-03-01 23:16:18.000000000 -0500
@@ -3,7 +3,10 @@
 local prev="$words[CURRENT-1]" file expl tmp is_gnu dir incl
 
 expandVars() {
-    local open close var val tmp=$1 ret=$1
+    local open close var val tmp=$2 ret=$2
+    if (( $1 == 0 )); then
+	return
+    fi
     while :; do
 	var=${tmp#*\$}
 	if [[ $var != $tmp ]]; then
@@ -37,7 +40,7 @@
 	    case $var in
 	    ([[:alnum:]_]#)
 		val=${(P)var}
-		val=$(expandVars $val)
+		val=$(expandVars $(($1 - 1)) $val)
 		ret=${ret//\$$open$var$close/$val}
 		;;
 	    esac
@@ -63,12 +66,12 @@
 	    var=${input%%[ $TAB]#:=*}
 	    val=${input#*=}
 	    val=${val##[ $TAB]#}
-	    val=$(expandVars $val)
+	    val=$(expandVars 10 $val)
 	    eval $var=\$val
 	    ;;
 	([[:alnum:]][^$TAB:=]#:[^=]*)
 	    input=${input%%:*}
-	    print $(expandVars $input)
+	    print $(expandVars 10 $input)
 	    ;;
 	($incl *)
 	    local f=${input##$incl ##}
@@ -76,7 +79,7 @@
 		f=${f#[\"<]}
 		f=${f%[\">]}
 	    fi
-	    f=$(expandVars $f)
+	    f=$(expandVars 10 $f)
 	    case $f in
 	    (/*) ;;
 	    (*)  f=$dir/$f ;;




----- End forwarded message -----

Re: [stew@vireo.org: Bug#295511: patch]

[Wayne Davison]

On Wed, Mar 02, 2005 at 12:28:45AM -0500, Clint Adams wrote:
> Wayne, any thoughts?

Hmm, I failed to notice that this Debian bug was talking about the _make
completer.  It looks to me like the main problem is that the script has
a reference to $1 in some $(shell ...) expansions, and the _make script
is expanding this into the arg that is being expanded, causing an
infinite loop.  So, I think it would be good to work up a patch that
would cause the _make script to avoid trying to expand (or set) numeric
arg variables (I'll look into this).

However, the patch you cited that limits recursion-depth also appears to
be a reasonable precaution to avoid a problem like this in the future.
It looks good enough to check-in to me -- if you agree, feel free (or
ask me to do so).

..wayne..

Re: [stew@vireo.org: Bug#295511: patch]

[Wayne Davison]

On Wed, Mar 02, 2005 at 10:51:47AM -0800, Wayne Davison wrote:
> So, I think it would be good to work up a patch that would cause the
> _make script to avoid trying to expand (or set) numeric arg variables

The fix to avoid expanding something like $1 was trivial, so I checked
it in to both the trunk and the patches branch:

--- Completion/Unix/Command/_make	11 Nov 2004 19:05:25 -0000	1.14
+++ Completion/Unix/Command/_make	2 Mar 2005 19:06:23 -0000	1.15
@@ -17,7 +17,7 @@ expandVars() {
 		open='{'
 		close='}'
 		;;
-	    ([[:alnum:]]*)
+	    ([[:alpha:]]*)
 		open=''
 		close=''
 		var=${(s::)var[1]}

This change avoids the infinite recursion cited in Debug bug #295511.

..wayne..

Re: [stew@vireo.org: Bug#295511: patch]

[Clint Adams]

> However, the patch you cited that limits recursion-depth also appears to
> be a reasonable precaution to avoid a problem like this in the future.
> It looks good enough to check-in to me -- if you agree, feel free (or
> ask me to do so).

Okay, I'll commit it.