buggy CSH_NULL_GLOB when a pattern is at the command position

buggy CSH_NULL_GLOB when a pattern is at the command position

[Vincent Lefevre]

When CSH_NULL_GLOB is set and the command line contains only patterns,
a "no match" error is not reported.

Without CSH_NULL_GLOB:

zira% []
zsh: no matches found: []

With CSH_NULL_GLOB:

zira% setopt CSH_NULL_GLOB
zira% []
zira% [] []
zira% [] echo foo
foo

but

zira% echo []
zsh: no match

is OK.

Moreover, I wonder whether when a no-match pattern is at the
command position, one should always get an error (if possible).

BTW, with older zsh versions, such as 5.0.7, [] was regarded
as a bad pattern (instead of a pattern that doesn't match).
Has this changed on purpose?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Bart Schaefer]

On Jan 1,  5:00am, Vincent Lefevre wrote:
}
} When CSH_NULL_GLOB is set and the command line contains only patterns,
} a "no match" error is not reported.

Hm.  So what's happening here is that the error is suppressed in zglob()
because it should only be reported if all globbing fails; but because
the command position is globbed separately from the rest of the line,
the caller is not expecting to handle this condition and glob failure
is interpreted as an empty command line.

You can see how this happens better if written this way:

torch% [] echo foo
foo

The [] is discarded because of cshnullglob, so "echo" is actually the
command.

The patch below fixes the case where all command-position globs fail,
although the error message is not the same as when cshnullglob is not set
(which has always been true in other cases, so probably not a big deal).

} Moreover, I wonder whether when a no-match pattern is at the
} command position, one should always get an error (if possible).

It's conceivable that somebody might actually *intend* the behavior in
my example above, though I don't know why.

} BTW, with older zsh versions, such as 5.0.7, [] was regarded
} as a bad pattern (instead of a pattern that doesn't match).
} Has this changed on purpose?

Seems so:

commit e86720190efc6550086e6a733394cb393cd0da4d
Author: Peter Stephenson <pws@zsh.org>
Date:   Fri May 15 09:35:24 2015 +0100

    35131: allow "[]" to match empty character set.


diff --git a/Src/exec.c b/Src/exec.c
index 18d19b6..352615c 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -2785,6 +2785,11 @@ execcmd(Estate state, int input, int output, int how, int last1)
 		     * arguments before and no command substitution
 		     * has provided a status.
 		     */
+		    if (badcshglob == 1) {
+			zerr("no match");
+			lastval = 1;
+			return;
+		    }
 		    cmdoutval = use_cmdoutval ? lastval : 0;
 		    if (varspc)
 			addvars(state, varspc, 0);

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

[Bart Schaefer]

On Jan 1, 12:39pm, Bart Schaefer wrote:
}
} The patch below fixes the case where all command-position globs fail

Hmm, there's something not quite right with that patch, perhaps.  Here
is zsh-5.2:

schaefer<501> [] *[c]*(e?'reply=(echo)'?)
echo echo echo echo echo echo echo echo echo

Here is current HEAD with my patch:

schaefer<501> [] *[c]*(e?'reply=(echo)'?)
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match
zsh: no match

I suspect badcshglob needs to be cleared (or saved/restored) somewhere.

-- 
Barton E. Schaefer

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

[Vincent Lefevre]

On 2016-01-01 12:39:40 -0800, Bart Schaefer wrote:
> On Jan 1,  5:00am, Vincent Lefevre wrote:
> }
> } When CSH_NULL_GLOB is set and the command line contains only patterns,
> } a "no match" error is not reported.
> 
> Hm.  So what's happening here is that the error is suppressed in zglob()
> because it should only be reported if all globbing fails; but because
> the command position is globbed separately from the rest of the line,
> the caller is not expecting to handle this condition and glob failure
> is interpreted as an empty command line.
> 
> You can see how this happens better if written this way:
> 
> torch% [] echo foo
> foo
> 
> The [] is discarded because of cshnullglob, so "echo" is actually the
> command.
> 
> The patch below fixes the case where all command-position globs fail,
> although the error message is not the same as when cshnullglob is not set
> (which has always been true in other cases, so probably not a big deal).
> 
> } Moreover, I wonder whether when a no-match pattern is at the
> } command position, one should always get an error (if possible).
> 
> It's conceivable that somebody might actually *intend* the behavior in
> my example above, though I don't know why.

Actually, I wonder whether I have ever used a glob at the command
position on purpose. And it seems that such a glob often does not
make sense because globbing doesn't take $path into account:

zira% which emacs
/usr/bin/emacs
zira% emac*
zsh: permission denied: emacs-bug

So, this would mean that one would need to use the full path:

zira% /usr/bin/emac*

which also doesn't make sense if it expands to several words like
here:

zira% echo /usr/bin/emac*
/usr/bin/emacs /usr/bin/emacs24 /usr/bin/emacs24-x /usr/bin/emacsclient /usr/bin/emacsclient.emacs24

So, independently of CSH_NULL_GLOB, perhaps there should be options
so that, at the user choice:

1) glob is not allowed at command position. But if really needed,
one can still do something like:

  command /usr/bin/emac*([1])

2) glob at command position is allowed, but fails if the number of
generated words is not exactly 1.

In my case, I think that I would be happy with (1).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Bart Schaefer]

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;