[lunz@falooley.org: Bug#279417: zsh: "make" completion issues "bad option" warnings for some Makefiles]

[lunz@falooley.org: Bug#279417: zsh: "make" completion issues "bad option" warnings for some Makefiles]

[Clint Adams]

Attachment mentioned in the forwarded message at the bottom is at
http://bugs.debian.org/cgi-bin/bugreport.cgi/Makefile?bug=279417&msg=3&att=1

This prevents the warnings, though I don't know if there's a deeper
problem occurring here.

Index: Completion/Unix/Command/_make
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_make,v
retrieving revision 1.11
diff -u -r1.11 _make
--- Completion/Unix/Command/_make	12 Oct 2004 20:05:13 -0000	1.11
+++ Completion/Unix/Command/_make	2 Nov 2004 23:09:54 -0000
@@ -38,7 +38,7 @@
 		;;
 	    esac
 	else
-	    print $ret
+	    print -- $ret
 	    return
 	fi
     done

----- Forwarded message from Jason Lunz <lunz@falooley.org> -----

Date: Tue, 02 Nov 2004 17:31:05 -0500
From: Jason Lunz <lunz@falooley.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#279417: zsh: "make" completion issues "bad option" warnings for some Makefiles

Package: zsh
Version: 4.2.1-9
Severity: normal


For some Makefiles, trying to complete make targets pollutes the screen
with error messages from within the completion code. For example:

	[barton](2) % make expandVars:36: bad option: -I
	expandVars:36: bad option: -W
	expandVars:36: bad option: -h
		make
	completions of type: file
	Makefile    x

The attached Makefile snippet reproduces the above behavior.

Jason


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-rc1
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

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

Re: [lunz@falooley.org: Bug#279417: zsh: "make" completion issues "bad option" warnings for some Makefiles]

[Wayne Davison]

On Tue, Nov 02, 2004 at 06:13:04PM -0500, Clint Adams wrote:
> This prevents the warnings, though I don't know if there's a deeper
> problem occurring here.

Your fix looks right to me for the root of the problem.

One other potential parsing problem that occurred to me while looking at
this was that "$$" wasn't being interpreted properly.  The following
patch should make it better (though not 100% foolproof, it should
hopefully be adequate for our purposes).

--- Completion/Unix/Command/_make	2 Nov 2004 23:26:42 -0000	1.12
+++ Completion/Unix/Command/_make	10 Nov 2004 17:18:53 -0000
@@ -22,6 +22,10 @@ expandVars() {
 		close=''
 		var=${(s::)var[1]}
 		;;
+	    (\$*)
+		# avoid parsing second $ in $$
+		tmp=${tmp#\$}
+		continue
 	    (*)
 		continue
 		;;
@@ -38,7 +42,7 @@ expandVars() {
 		;;
 	    esac
 	else
-	    print -- $ret
+	    print -- ${ret//\$\$/\$}
 	    return
 	fi
     done

..wayne..