zsh-users
 help / color / mirror / code / Atom feed
* unintuitive bracketing with return value
@ 2022-10-18 14:47 Ray Andrews
  2022-10-18 14:57 ` Eric Cook
  2022-10-18 16:07 ` Roman Perepelitsa
  0 siblings, 2 replies; 9+ messages in thread
From: Ray Andrews @ 2022-10-18 14:47 UTC (permalink / raw)
  To: Zsh Users

I vaguely remember mentioning this before but I don't recall what the 
understanding should be:

[ "${${1}##*[*?]*}" ] && {
echo "no wildcards"; printenv "$1" } || echo wildcards present

... I'm obviously testing for the presence of wildcards before sending 
"$1" to 'printenv', unfortunately the '||' responds to the return value 
of 'printenv' and not, as I intend, for the '||' to respond to the first 
test (presence of wildcards).  If it was not bracketed there would be no 
issue of course, but shouldn't the brackets do the intuitive thing and  
force the final '||' to be the alternative to the first '&&'?  It's easy 
to just write the thing as an 'if/else' statement and avoid the issue, 
but still the above seems very counter intuitive.  ... Tho of course one 
could get used to it and prefer it that way but still it seems weird.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 14:47 unintuitive bracketing with return value Ray Andrews
@ 2022-10-18 14:57 ` Eric Cook
  2022-10-18 17:57   ` Ray Andrews
  2022-10-18 16:07 ` Roman Perepelitsa
  1 sibling, 1 reply; 9+ messages in thread
From: Eric Cook @ 2022-10-18 14:57 UTC (permalink / raw)
  To: zsh-users

On 10/18/22 10:47, Ray Andrews wrote:
> I vaguely remember mentioning this before but I don't recall what the understanding should be:
>
> [ "${${1}##*[*?]*}" ] && {
> echo "no wildcards"; printenv "$1" } || echo wildcards present
>
> ... I'm obviously testing for the presence of wildcards before sending "$1" to 'printenv', unfortunately the '||' responds to the return value of 'printenv' and not, as I intend, for the '||' to respond to the first test (presence of wildcards).  If it
> was not bracketed there would be no issue of course, but shouldn't the brackets do the intuitive thing and force the final '||' to be the alternative to the first '&&'?  It's easy to just write the thing as an 'if/else' statement and avoid the issue, but
> still the above seems very counter intuitive.  ... Tho of course one could get used to it and prefer it that way but still it seems weird.
>
>
>

https://mywiki.wooledge.org/BashPitfalls#pf22


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 14:47 unintuitive bracketing with return value Ray Andrews
  2022-10-18 14:57 ` Eric Cook
@ 2022-10-18 16:07 ` Roman Perepelitsa
  1 sibling, 0 replies; 9+ messages in thread
From: Roman Perepelitsa @ 2022-10-18 16:07 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Tue, Oct 18, 2022 at 4:47 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> [...] shouldn't the brackets do the intuitive thing and
> force the final '||' to be the alternative to the first '&&'?

You seem to be thinking of `X && Y || Z` as a single construct but
there is no such thing. There is only `X && Y` and `X || Y`. In any
programming language I'm familiar with, these operators are
left-associative, short-circuit, and the result is always that of the
last evaluated operand. Short-circuiting means that the second operand
is evaluated by &&/|| if and only if the first operand is true/false.
There are two aspects on which programming languages differ when it
comes to these operators.

1. Is the result coerced to bool (0 or 1)? Yes in C (and other
statically-typed languages), no in Zsh (and other dynamically-typed
languages).
2. Does && have higher precedence than ||? Yes in C (and most
languages), no in Zsh (and all shells).

Once you know this, it should be clear why your program evaluates the
way it does.

So, how do you put this in practice? Use `if` when you need `if`. Use
`X && Y || Z` only when `if` would be wrong. However, even then it's
almost always better to do this:

  if ! X || ! Y; then
    Z
  fi

Roman.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 14:57 ` Eric Cook
@ 2022-10-18 17:57   ` Ray Andrews
  2022-10-18 19:32     ` Lawrence Velázquez
  0 siblings, 1 reply; 9+ messages in thread
From: Ray Andrews @ 2022-10-18 17:57 UTC (permalink / raw)
  To: zsh-users


On 2022-10-18 07:57, Eric Cook wrote:
>
> https://mywiki.wooledge.org/BashPitfalls#pf22
>
Very well written!  What breaks my intuition tho is the brackets.  
Otherwise I quite understand that the last exit value is the active 
one.  I'm expecting the brackets to 'contain' the rv of any commands 
within the brackets.  But no, the left > right rule applies and the 
brackets don't make any difference.

Roman:

1. Is the result coerced to bool (0 or 1)? Yes in C (and other
statically-typed languages), no in Zsh (and other dynamically-typed
languages).
2. Does && have higher precedence than ||? Yes in C (and most
languages), no in Zsh (and all shells).

... Even after all these years I still think in C.  And, as Peter 
explains, the braces don't really change anything at all, the last rv is 
still the last rv.  Indeed, it's best to stick with if/else and avoid 
these little things.  I really shouldn't have to have these basics 
explained over and over :(





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 17:57   ` Ray Andrews
@ 2022-10-18 19:32     ` Lawrence Velázquez
  2022-10-18 20:12       ` Bart Schaefer
  2022-10-18 20:22       ` Ray Andrews
  0 siblings, 2 replies; 9+ messages in thread
From: Lawrence Velázquez @ 2022-10-18 19:32 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Oct 18, 2022, at 1:57 PM, Ray Andrews wrote:
> On 2022-10-18 07:57, Eric Cook wrote:
>>
>> https://mywiki.wooledge.org/BashPitfalls#pf22
>>
> Very well written!  What breaks my intuition tho is the brackets.  
> Otherwise I quite understand that the last exit value is the active 
> one.  I'm expecting the brackets to 'contain' the rv of any commands 
> within the brackets.  But no, the left > right rule applies and the 
> brackets don't make any difference.

I don't understand why you keep saying this.  Without the braces
your command would be completely different.  This:

    [ "${${1}##*[*?]*}" ] &&
    echo "no wildcards"; printenv "$1" ||
    echo wildcards present

is equivalent to this:

    [ "${${1}##*[*?]*}" ] && echo "no wildcards"
    printenv "$1" || echo wildcards present

which is not at all what you want.

-- 
vq


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 19:32     ` Lawrence Velázquez
@ 2022-10-18 20:12       ` Bart Schaefer
  2022-10-18 20:14         ` Bart Schaefer
  2022-10-18 20:22       ` Ray Andrews
  1 sibling, 1 reply; 9+ messages in thread
From: Bart Schaefer @ 2022-10-18 20:12 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users

On Tue, Oct 18, 2022 at 12:33 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> On Tue, Oct 18, 2022, at 1:57 PM, Ray Andrews wrote:
> > Very well written!  What breaks my intuition tho is the brackets.
> > Otherwise I quite understand that the last exit value is the active
> > one.  I'm expecting the brackets to 'contain' the rv of any commands
> > within the brackets.  But no, the left > right rule applies and the
> > brackets don't make any difference.
>
> I don't understand why you keep saying this.  Without the braces
> your command would be completely different.

I think Ray's just got the opening bracket in the wrong place.  He's
describing the bracketing as if it were this:

{ "${${1}##*[*?]*}" ] &&
echo "no wildcards"; printenv "$1" } || echo wildcards present

which would do exactly what he wants.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 20:12       ` Bart Schaefer
@ 2022-10-18 20:14         ` Bart Schaefer
  0 siblings, 0 replies; 9+ messages in thread
From: Bart Schaefer @ 2022-10-18 20:14 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users

On Tue, Oct 18, 2022 at 1:12 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> describing the bracketing as if it were this:

Except for my copy-paste error, of course.  Put a "[" inside the "{".

> { "${${1}##*[*?]*}" ] &&
> echo "no wildcards"; printenv "$1" } || echo wildcards present
>
> which would do exactly what he wants.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 19:32     ` Lawrence Velázquez
  2022-10-18 20:12       ` Bart Schaefer
@ 2022-10-18 20:22       ` Ray Andrews
  2022-10-18 20:31         ` Clinton Bunch
  1 sibling, 1 reply; 9+ messages in thread
From: Ray Andrews @ 2022-10-18 20:22 UTC (permalink / raw)
  To: zsh-users


On 2022-10-18 12:32, Lawrence Velázquez wrote:
> is equivalent to this:
>
>      [ "${${1}##*[*?]*}" ] && echo "no wildcards"
>      printenv "$1" || echo wildcards present
>
> which is not at all what you want.

Quite right, I expressed it poorly.  Anyway the issue is closed, I 
understand it.  I wonder how old I'll have to be before I stop thinking 
in C.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: unintuitive bracketing with return value
  2022-10-18 20:22       ` Ray Andrews
@ 2022-10-18 20:31         ` Clinton Bunch
  0 siblings, 0 replies; 9+ messages in thread
From: Clinton Bunch @ 2022-10-18 20:31 UTC (permalink / raw)
  To: zsh-users


On 10/18/2022 3:22 PM, Ray Andrews wrote:
>
> On 2022-10-18 12:32, Lawrence Velázquez wrote:
>> is equivalent to this:
>>
>>      [ "${${1}##*[*?]*}" ] && echo "no wildcards"
>>      printenv "$1" || echo wildcards present
>>
>> which is not at all what you want.
>
> Quite right, I expressed it poorly.  Anyway the issue is closed, I 
> understand it.  I wonder how old I'll have to be before I stop 
> thinking in C.


Try perl.  Then you'll really be confused as to the proper syntax. :)

>
>
>


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-10-18 20:32 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-18 14:47 unintuitive bracketing with return value Ray Andrews
2022-10-18 14:57 ` Eric Cook
2022-10-18 17:57   ` Ray Andrews
2022-10-18 19:32     ` Lawrence Velázquez
2022-10-18 20:12       ` Bart Schaefer
2022-10-18 20:14         ` Bart Schaefer
2022-10-18 20:22       ` Ray Andrews
2022-10-18 20:31         ` Clinton Bunch
2022-10-18 16:07 ` Roman Perepelitsa

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