* Re: [BUG] Condition in [[ doesn't fire, with "if" it fires
[not found] ` <1488281256.2881475.895357184.6106CE5C@webmail.messagingengine.com>
@ 2017-02-28 11:51 ` Peter Stephenson
2017-02-28 12:17 ` Sebastian Gniazdowski
2017-03-01 12:01 ` Peter Stephenson
0 siblings, 2 replies; 3+ messages in thread
From: Peter Stephenson @ 2017-02-28 11:51 UTC (permalink / raw)
To: Zsh Users' List
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] Condition in [[ doesn't fire, with "if" it fires
2017-02-28 11:51 ` [BUG] Condition in [[ doesn't fire, with "if" it fires Peter Stephenson
@ 2017-02-28 12:17 ` Sebastian Gniazdowski
2017-03-01 12:01 ` Peter Stephenson
1 sibling, 0 replies; 3+ messages in thread
From: Sebastian Gniazdowski @ 2017-02-28 12:17 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] Condition in [[ doesn't fire, with "if" it fires
2017-02-28 11:51 ` [BUG] Condition in [[ doesn't fire, with "if" it fires Peter Stephenson
2017-02-28 12:17 ` Sebastian Gniazdowski
@ 2017-03-01 12:01 ` Peter Stephenson
1 sibling, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 2017-03-01 12:01 UTC (permalink / raw)
To: Zsh Users' List
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-01 12:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1488280289.2878360.895324176.3971EE76@webmail.messagingengine.com>
[not found] ` <CGME20170228112804epcas2p2e241ff0013d6ac1cae21987a41442ce8@epcas2p2.samsung.com>
[not found] ` <1488281256.2881475.895357184.6106CE5C@webmail.messagingengine.com>
2017-02-28 11:51 ` [BUG] Condition in [[ doesn't fire, with "if" it fires Peter Stephenson
2017-02-28 12:17 ` Sebastian Gniazdowski
2017-03-01 12:01 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).