Re: [BUG] Condition in [[ doesn't fire, with "if" it fires

Re: [BUG] Condition in [[ doesn't fire, with "if" it fires

[Peter Stephenson]

On Tue, 28 Feb 2017 03:27:36 -0800
Sebastian Gniazdowski <psprint3@fastmail.com> wrote:
> Checked that even:
> 
>     [[ "below" = "below" ]] && (( line ++ )) || (( line = stborder ))
> 
> doesn't fire. In the same way. It is the false option that is fired:

Ah, I see what you've done now.  I moved this to zsh-users because this
is an interesting point and the above should give folks enough context
to see what I'm talking about; look at zsh-workers for more background.

&& and || don't work the way they do in C, they are simply evaluated
left to right in a symmetric fashion.  (Yes, another shell oddity dating
from year zero for Ray to moan about.)  Have a look at the grammar tests
for some example.

In detail:

- Test succeeds.

- So (( line ++ )) run

- line was zero, and with a post increment the value is zero, so status
is 1.

- (This is the unexpected bit.)  On a non-zero status, the shell looks
forward for the next ||, ignoring any &&'s.  As I said, there is no
relative priority, just a strict left to right evaluation.

- So it then executes (( line = stborder ))

- I'm guessing stborder is 0, so that's what line is set to.

You *could* fix this up by switching to a pre-increment, but I'd
recommend just going to if/then/else --- it's much more obvious what the
logic actually means.

pws

Re: [BUG] Condition in [[ doesn't fire, with "if" it fires

[Sebastian Gniazdowski]

On Tue, Feb 28, 2017, at 03:51 AM, Peter Stephenson wrote:
> You *could* fix this up by switching to a pre-increment, but I'd
> recommend just going to if/then/else --- it's much more obvious what the
> logic actually means.

Hah, had trained a habit to not like post-increment, knowing what it
does in C++ as overloaded operator, but this time I omitted.. But maybe
it's good, a very interesting oddity revealed, thanks.

-- 
  Sebastian Gniazdowski
  psprint3@fastmail.com

Re: [BUG] Condition in [[ doesn't fire, with "if" it fires

[Peter Stephenson]

On Tue, 28 Feb 2017 11:51:58 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Tue, 28 Feb 2017 03:27:36 -0800
> Sebastian Gniazdowski <psprint3@fastmail.com> wrote:
> > Checked that even:
> > 
> >     [[ "below" = "below" ]] && (( line ++ )) || (( line = stborder ))
> > 
> > doesn't fire. In the same way. It is the false option that is fired:
> 
> && and || don't work the way they do in C, they are simply evaluated
> left to right in a symmetric fashion.

While that's true, I suppose I ought to point out, for anyone trying to
learn something from this, that in this particular case the logic
happens to work the same as C.  zsh does { X && Y } || Z because of left
to right evaluation, C does (X && Y) || Z beause of precedence.

The oddity causing the problem was the (( ... )) return status non-zero,
rather than the logical ordering, which is a rather different point.

Where it's very different from C is

X || Y && Z

which is effectively  { X || Y } && Z in zsh, because it's simply left
to right, and X || (Y && Z) in C because of precedence.  There's nothing
to stop you writing X || { Y && Z } in zsh to group explicitly, however.

Now back to normal service.

pws