* [[ 0 =~ 1 || 1 = 0 ]] returns true
@ 2010-10-09 17:29 Mikael Magnusson
2010-10-09 20:06 ` Michael Hwang
0 siblings, 1 reply; 6+ messages in thread
From: Mikael Magnusson @ 2010-10-09 17:29 UTC (permalink / raw)
To: zsh workers; +Cc: brandon
% [[ 1 =~ 1 && 0 = 1 ]]; echo $?
0
% [[ 1 =~ 1 || 0 = 1 ]]; echo $?
0
% [[ 1 =~ 0 || 0 = 1 ]]; echo $?
0
% [[ 1 =~ 0 || 1 = 1 ]]; echo $?
1
% [[ 1 =~ 1 || 1 = 1 ]]; echo $?
0
% [[ 1 =~ 1 && 1 = 1 ]]; echo $?
1
% [[ 1 =~ 0 && 1 = 1 ]]; echo $?
1
Something seems to be screwy with =~ and &&/||, on its own it appears fine.
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [[ 0 =~ 1 || 1 = 0 ]] returns true
2010-10-09 17:29 [[ 0 =~ 1 || 1 = 0 ]] returns true Mikael Magnusson
@ 2010-10-09 20:06 ` Michael Hwang
2010-10-09 22:17 ` Phil Pennock
0 siblings, 1 reply; 6+ messages in thread
From: Michael Hwang @ 2010-10-09 20:06 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: zsh workers, brandon
% set -x
% [[ 0 =~ 1 || 1 = 0 ]]
+zsh:2> [[ 0 -regex-match 1 || ! 1 == 0 ]]
% [[ 0 =~ 1 || 1 == 1 || 1 = 0 ]]
+zsh:3> [[ 0 -regex-match 1 || ! 1 == 1 ]]
% [[ 0 =~ 1 || 1 == 1 || 1 = 1 || 1 = 1 || 1 = 1 ]]
+zsh:4> [[ 0 -regex-match 1 || ! 1 == 1 ]]
It appears that zsh thinks it needs to invert the second conditional
expression. Also, zsh seems to drop more than two conditional
expressions.
Michael Hwang
On Sat, Oct 9, 2010 at 1:29 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> % [[ 1 =~ 1 && 0 = 1 ]]; echo $?
> 0
> % [[ 1 =~ 1 || 0 = 1 ]]; echo $?
> 0
> % [[ 1 =~ 0 || 0 = 1 ]]; echo $?
> 0
> % [[ 1 =~ 0 || 1 = 1 ]]; echo $?
> 1
> % [[ 1 =~ 1 || 1 = 1 ]]; echo $?
> 0
> % [[ 1 =~ 1 && 1 = 1 ]]; echo $?
> 1
> % [[ 1 =~ 0 && 1 = 1 ]]; echo $?
> 1
>
> Something seems to be screwy with =~ and &&/||, on its own it appears fine.
>
> --
> Mikael Magnusson
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [[ 0 =~ 1 || 1 = 0 ]] returns true
2010-10-09 20:06 ` Michael Hwang
@ 2010-10-09 22:17 ` Phil Pennock
2010-11-02 16:34 ` Brandon Philips
0 siblings, 1 reply; 6+ messages in thread
From: Phil Pennock @ 2010-10-09 22:17 UTC (permalink / raw)
To: Michael Hwang; +Cc: Mikael Magnusson, zsh workers, brandon
On 2010-10-09 at 16:06 -0400, Michael Hwang wrote:
> % set -x
> % [[ 0 =~ 1 || 1 = 0 ]]
> +zsh:2> [[ 0 -regex-match 1 || ! 1 == 0 ]]
> % [[ 0 =~ 1 || 1 == 1 || 1 = 0 ]]
> +zsh:3> [[ 0 -regex-match 1 || ! 1 == 1 ]]
> % [[ 0 =~ 1 || 1 == 1 || 1 = 1 || 1 = 1 || 1 = 1 ]]
> +zsh:4> [[ 0 -regex-match 1 || ! 1 == 1 ]]
>
> It appears that zsh thinks it needs to invert the second conditional
> expression. Also, zsh seems to drop more than two conditional
> expressions.
The dropping is short-circuiting, the same as in all shell evaluation of
&& and ||. The shell stops once it knows enough to know the answer. So
false to the left of && will stop, and true to the left of || will stop.
% [[ 1 == 1 && 3 == 2 && 4 == 4 && sb == sb ]]
+zsh:12> [[ 1 == 1 && 3 == 2 ]]
% [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
+zsh:13> [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
So the issue appears to just be what the OP wrote, that =~ is messing up
&&/|| by inserting a sense inversion.
% [[ 1 =~ 0 || 1 == 1 ]]
+zsh:18> [[ 1 -regex-match 0 || ! 1 == 1 ]]
% [[ 1 -regex-match 0 || 1 == 1 ]]
+zsh:19> [[ 1 -regex-match 0 || 1 == 1 ]]
So it's related to use of =~ rather than -regex-match. It's independent
of whether or not zsh/pcre is loaded. So this is probably a bug which I
introduced when I wrote the =~ syntax support. Looking now.
-Phil
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [[ 0 =~ 1 || 1 = 0 ]] returns true
2010-10-09 22:17 ` Phil Pennock
@ 2010-11-02 16:34 ` Brandon Philips
2010-11-02 20:41 ` Mikael Magnusson
2010-11-02 23:37 ` Phil Pennock
0 siblings, 2 replies; 6+ messages in thread
From: Brandon Philips @ 2010-11-02 16:34 UTC (permalink / raw)
To: Michael Hwang, Mikael Magnusson, zsh workers
On 18:17 Sat 09 Oct 2010, Phil Pennock wrote:
> The dropping is short-circuiting, the same as in all shell evaluation of
> && and ||. The shell stops once it knows enough to know the answer. So
> false to the left of && will stop, and true to the left of || will stop.
>
> % [[ 1 == 1 && 3 == 2 && 4 == 4 && sb == sb ]]
> +zsh:12> [[ 1 == 1 && 3 == 2 ]]
> % [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
> +zsh:13> [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
>
> So the issue appears to just be what the OP wrote, that =~ is messing up
> &&/|| by inserting a sense inversion.
>
> % [[ 1 =~ 0 || 1 == 1 ]]
> +zsh:18> [[ 1 -regex-match 0 || ! 1 == 1 ]]
> % [[ 1 -regex-match 0 || 1 == 1 ]]
> +zsh:19> [[ 1 -regex-match 0 || 1 == 1 ]]
>
> So it's related to use of =~ rather than -regex-match. It's independent
> of whether or not zsh/pcre is loaded. So this is probably a bug which I
> introduced when I wrote the =~ syntax support. Looking now.
Did you find anything? Curious on what the state of this is.
Let me know if I can help.
Thanks,
Brandon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [[ 0 =~ 1 || 1 = 0 ]] returns true
2010-11-02 16:34 ` Brandon Philips
@ 2010-11-02 20:41 ` Mikael Magnusson
2010-11-02 23:37 ` Phil Pennock
1 sibling, 0 replies; 6+ messages in thread
From: Mikael Magnusson @ 2010-11-02 20:41 UTC (permalink / raw)
To: Brandon Philips; +Cc: zsh workers
On 2 November 2010 17:34, Brandon Philips <brandon@ifup.org> wrote:
> On 18:17 Sat 09 Oct 2010, Phil Pennock wrote:
>> The dropping is short-circuiting, the same as in all shell evaluation of
>> && and ||. The shell stops once it knows enough to know the answer. So
>> false to the left of && will stop, and true to the left of || will stop.
>>
>> % [[ 1 == 1 && 3 == 2 && 4 == 4 && sb == sb ]]
>> +zsh:12> [[ 1 == 1 && 3 == 2 ]]
>> % [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
>> +zsh:13> [[ 1 == 1 && 3 != 2 && 4 == 4 && sb == sb ]]
>>
>> So the issue appears to just be what the OP wrote, that =~ is messing up
>> &&/|| by inserting a sense inversion.
>>
>> % [[ 1 =~ 0 || 1 == 1 ]]
>> +zsh:18> [[ 1 -regex-match 0 || ! 1 == 1 ]]
>> % [[ 1 -regex-match 0 || 1 == 1 ]]
>> +zsh:19> [[ 1 -regex-match 0 || 1 == 1 ]]
>>
>> So it's related to use of =~ rather than -regex-match. It's independent
>> of whether or not zsh/pcre is loaded. So this is probably a bug which I
>> introduced when I wrote the =~ syntax support. Looking now.
>
> Did you find anything? Curious on what the state of this is.
>
> Let me know if I can help.
It was fixed in cvs not long after this. I think the fix-mail started
a new thread somewhere.
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [[ 0 =~ 1 || 1 = 0 ]] returns true
2010-11-02 16:34 ` Brandon Philips
2010-11-02 20:41 ` Mikael Magnusson
@ 2010-11-02 23:37 ` Phil Pennock
1 sibling, 0 replies; 6+ messages in thread
From: Phil Pennock @ 2010-11-02 23:37 UTC (permalink / raw)
To: Brandon Philips; +Cc: Michael Hwang, Mikael Magnusson, zsh workers
On 2010-11-02 at 09:34 -0700, Brandon Philips wrote:
> Did you find anything? Curious on what the state of this is.
Fixed in:
http://www.zsh.org/mla/workers/2010/msg00784.html
Subject: [PATCH]: =~ parsing littering pattern state fix
within a couple of hours of my first response. Fixed, regression test
added.
-Phil
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-11-02 23:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-09 17:29 [[ 0 =~ 1 || 1 = 0 ]] returns true Mikael Magnusson
2010-10-09 20:06 ` Michael Hwang
2010-10-09 22:17 ` Phil Pennock
2010-11-02 16:34 ` Brandon Philips
2010-11-02 20:41 ` Mikael Magnusson
2010-11-02 23:37 ` Phil Pennock
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).