Re: <n> == <n->?

[Zefram <zefram@fysh.org>]

[Johan Sundstr_m] wrote:
>Sounds reasonable. After some digging through zshmisc(1), I'd guess the
>situation we're trying to protect from a possible ambiguity is "< word" --
>am I right?

Right right.

>            I may be at a loss here, but I don't quite see where the
>problem might arise. Could someone depict an example or two and how to
>trigger the problem?

	cat <123-456>foo

zsh treats this as a command line with two words, one of which is a glob
pattern that will match "00234foo" and so on.  Bourne shell syntax has
this meaning the same as the way both zsh and sh interpret

	cat <123-456 >foo

which is a command line with one word and two redirections (input from
"123-456", output to "foo").  It's quite common to omit spaces before
and after redirection operators.

>I noticed them being different (which showed better using cat than echo),
>but I failed to understand how the first case tried to operate; to me, it
>seemed like a broken effort at <<- or <<<, but then I guess I just didn't
>understand what happened, so my guess isn't worth a lot. :-]

What actually happens if you type "echo a<1" (before my patch) is that
the lexer sees a word "echo", then sees another word that starts with
"a".  After the "<", it looks for a ">" to finish that glob operator;
it gets a newline, which is treated as part of the word, then it asks
for more input, still reading that word.  Try typing "x>y" as the second
input line to complete the word.

Completely broken behaviour, nothing to do with here documents.

>Either way, I'm not sure I see the impact of this on the case where the
>word continues with a > and possibly more pattern matching. After all,
>when I want redirection, I don't try my luck at inserting a < or > in
>the middle of the current word I'm typing,

Quite.  The practical rarity of the syntax clash is the only reason that
we can get away with that as a glob syntax.  The reason for requiring the
"-" is to make the clash as small and as simply bounded as possible.

>                                           and I haven't found anything in
>the man pages supporting that behaviour either.

It's not clear on where whitespace is permitted.  Whitespace is allowed
but not required before and after redirection operators.

-zefram