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.