Re: buggy CSH_NULL_GLOB when a pattern is at the command position

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 1,  1:10pm, Bart Schaefer wrote:
}
} I suspect badcshglob needs to be cleared (or saved/restored) somewhere.

Patch below handles this.

Here's another odd cshnullglob buglet which is present as far back as
zsh-4.2.0, perhaps farther:

torch% echo []
zsh: no match
torch% echo [] *[c]*(e?'return 0'?)
config.h
torch% echo [] *[c]*(e?'return 0'?)
config.h config.log config.modules config.modules.sh config.status Doc Etc Src

That is, the first time a no-op (e) qualifier appears after a failed
cshnullglob, exactly one file is returned, even if more matches are
possible.  This must (?) be another case of badcshglob needing to be
reset, but I haven't tracked it down yet.


diff --git a/Src/glob.c b/Src/glob.c
index 94b3f62..8bd2fc4 100644
--- a/Src/glob.c
+++ b/Src/glob.c
@@ -3802,13 +3802,16 @@ qualsheval(char *name, UNUSED(struct stat *buf), UNUSED(off_t days), char *str)
 
     if ((prog = parse_string(str, 0))) {
 	int ef = errflag, lv = lastval, ret;
+	int cshglob = badcshglob;
 
 	unsetparam("reply");
 	setsparam("REPLY", ztrdup(name));
+	badcshglob = 0;
 
 	execode(prog, 1, 0, "globqual");
 
-	ret = lastval;
+	if ((ret = lastval))
+	    badcshglob |= cshglob;
 	/* Retain any user interrupt error status */
 	errflag = ef | (errflag & ERRFLAG_INT);
 	lastval = lv;