* 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).