Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: grammar triviality with '&&'

On 03/01/2015 06:27 PM, Vincent Lefevre wrote:
On 2015-03-01 13:49:38 -0500, Lawrence Velázquez wrote:
On Mar 1, 2015, at 12:01 PM, Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:
[...] From zshmisc(1):

     A list is a sequence of zero or more sublists, in which each sublist
     is terminated  by `;', `&', `&|', `&!', or a newline.

In your second example, `[ -e file1 ]` constitutes a list.
However "&& [ -e file2 ]" could constitute a list too. There is
currently a parse error, but zsh could have an extension to accept
it as being equivalent to: "[[ $? -eq 0 ]] && [ -e file2 ]". Would
there be anything wrong with such an extension?

Similarly, "|| X" could be regarded as equivalent to
"[[ $? -ne 0 ]] || X" by zsh.

I always thought of '&&' as logically equivalent to a keyword 'andif'
and '||' as 'orif' which is why I like to put them first on a line,
because we always put keywords first (mostly),
but it seems to me that even with Bart's definition of a 'hard'
syntax problem with the de-facto semicolon, if

[ -e file ]

... by itself on a line is legal, and if it returns success or failure
and if that success or failure is there for checking on the next
line, the '&&' could mean nothing else but 'check previous true/false',
so it should be unambiguous, so why wouldn't it be legal? It would be the
same as:

[ -e file ]; && ....

... which throws an error, but where is the ambiguity?  What else could it
mean?  Seems to me the semi doesn't/shouldn't change anything.

BTW, is there somewhere to read up on the 'list' idea, it's the first
I've ever heard of that concept.

Messages sorted by: Reverse Date, Date, Thread, Author