Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160101191155.ZM20298@torch.brasslantern.com>
Date: Fri, 1 Jan 2016 19:11:55 -0800
In-Reply-To: <160101131059.ZM10597@torch.brasslantern.com>
Comments: In reply to Bart Schaefer <schaefer@brasslantern.com>
        "Re: buggy CSH_NULL_GLOB when a pattern is at the command position" (Jan  1,  1:10pm)
References: <20160101040052.GA1808@zira.vinc17.org> 
	<160101123940.ZM10365@torch.brasslantern.com> 
	<160101131059.ZM10597@torch.brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: buggy CSH_NULL_GLOB when a pattern is at the command position
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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;