Re: grammar triviality with '&&'

[Kurtis Rader <krader@xxxxxxxxxxxxx>]

On Sun, Mar 1, 2015 at 8:18 PM, Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:

> Well, what would the costs be?  It looks to me that the error is an
> arbitrary restriction and if it didn't break something I'd remove it even
> if for no  other reason that that it is arbitrary.  Of course if there were
> any complications, then it shouldn't be touched.  Oh, and of course no one
> has to use it if they think it would ruffle anyone's feathers as far as
> tradition, but I'd use it for  sure. Things should only be limited where it
> is necessary that they be limited.  I'd not be surprised if the code was
> actually simpler, '&&' would just grab the errorlevel of the previous
> command as always and there'd just be one less error to handle.
>

One obvious cost is that anyone reading a script that uses the feature will
naturally assume the author made a mistake and the script is invalid. The
reason this restriction exists is not arbitrary. It is a an obvious and
natural consequence of how the grammar was interpreted by the person(s) who
wrote the code for the Bourne-shell, Bash, Zsh, etcetera. Why is it simpler
for the code to "just grab the errorlevel of the previous command"  when it
sees a leading "&&" or "||"? Also, it is not just a matter of changing the
zsh implementation. Unit tests need to be added and existing tests likely
updated. Documentation needs to be changed. Whether the change might break
existing uses has to be carefully considered.

You say "I'd use it for sure". Please provide a non-contrived example,
preferably two or three, where this would be useful. How hard is it to be
explicit and include the "[[ $? -eq 0 ]]" in a script? If this feature were
truly useful for interactive use I might agree with you. But I see no
evidence and my 30+ years experience that it has no use outside of making a
tiny percentage of scripts a few characters shorter.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank