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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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@xxxxxxx>
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);