Re: grammar triviality with '&&'

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2015-03-02 08:49:58 -0800, Bart Schaefer wrote:
> On Mar 2, 11:31am, Vincent Lefevre wrote:
> } Subject: Re: grammar triviality with '&&'
> }
> } On 2015-03-02 00:54:40 -0800, Bart Schaefer wrote:
> } > 
> } > If nothing else, the errexit option would fail.  With errexit,
> } 
> } I agree that's not equivalent, but this would not be a problem
> } in a "if ... then" construct (though I think it's a bad idea
> } to use such a feature here).
> 
> Except that's exactly where Ray wants to use it!

The feature would be there. Then every programmer is free to do what
he likes.

> 
> } > You also get strange crap like
> } > 
> } >     while && this; do || if && that; then || thus; fi; done
> } > 
> } > which would mean what, exactly?
> } 
> } while [[ $? -eq 0 ]] && this; do [[ $? -ne 0 ]] || if [[ $? -eq 0 ]] && that; then [[ $? -ne 0 ]] || thus; fi; done
> 
> Yes obviously that's what you intend the literal interpretation to be,
> but in what way is it sensibly meaningful in an actual program?

A programmer is not forced to use this feature. Anyway even

  while [[ $? -eq 0 ]] && this; do [[ $? -ne 0 ]] || if [[ $? -eq 0 ]] && that; then [[ $? -ne 0 ]] || thus; fi; done

is not really meaningful while this can already be done in zsh.

> } > Finally if it's OK to have nothing before && / ||, then it would also be
> } > syntactically OK to write
> } > 
> } >     && || && || && && ...
> } 
> } I disagree. Only a && or || as the first word of a list would have
> } a special meaning.
> 
> You can't escape the lunacy that easily:
> 
>     && { || { && { || { && { && ... } } } } }

Same as above. It would not be the first shell feature that could
be misused (see IFS and heredoc, for instance).

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - 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)