Ctrl-c not working during correction with 5.1

Ctrl-c not working during correction with 5.1

[Markus Trippelsdorf]

I cannot abort a correction with Ctrl-c anymore, e.g.:

markus@x4 tmp % la
zsh: correct 'la' to 'lz' [nyae]? <press Ctrl-c and nothing happens>

-- 
Markus

Re: Ctrl-c not working during correction with 5.1

[Bart Schaefer]

On Sep 1,  4:10pm, Markus Trippelsdorf wrote:
}
} I cannot abort a correction with Ctrl-c anymore, e.g.:
} 
} markus@x4 tmp % la
} zsh: correct 'la' to 'lz' [nyae]? <press Ctrl-c and nothing happens>

Unintended side-effect of all the race-condition-prevention work that
went on this summer.

diff --git a/Src/utils.c b/Src/utils.c
index 4c4dc55..90f7c33 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2538,11 +2538,16 @@ static int
 read1char(int echo)
 {
     char c;
+    int q = queue_signal_level();
 
+    dont_queue_signals();
     while (read(SHTTY, &c, 1) != 1) {
-	if (errno != EINTR || errflag || retflag || breaks || contflag)
+	if (errno != EINTR || errflag || retflag || breaks || contflag) {
+	    restore_queue_signals(q);
 	    return -1;
+	}
     }
+    restore_queue_signals(q);
     if (echo)
 	write_loop(SHTTY, &c, 1);
     return STOUC(c);

-- 
Barton E. Schaefer

Re: Ctrl-c not working during correction with 5.1

[Christian Neukirchen]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Sep 1,  4:10pm, Markus Trippelsdorf wrote:
> }
> } I cannot abort a correction with Ctrl-c anymore, e.g.:
> } 
> } markus@x4 tmp % la
> } zsh: correct 'la' to 'lz' [nyae]? <press Ctrl-c and nothing happens>
>
> Unintended side-effect of all the race-condition-prevention work that
> went on this summer.

Could this also be related to this glitch?

zsh 5.1 (x86_64-unknown-linux-gnu)
zsh-5.1-0-g11189c6
% zsh -f
juno% setopt NOALWAYSLASTPROMPT PROMPT_SUBST
juno% PS1='$(echo foo)%# '
foo% ls /usr/share/man/man1/<PRESS TAB HERE>
zsh: do you wish to see all 2528 possibilities (1264 lines)? <PRESS ^C HERE>n
$(echo ls /usr/share/man/man1/
foo% 

Somehow the unevaluated PS1 is printed.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Ctrl-c not working during correction with 5.1

[Bart Schaefer]

On Sep 2,  3:10pm, Christian Neukirchen wrote:
} Subject: Re: Ctrl-c not working during correction with 5.1
}
} Bart Schaefer <schaefer@brasslantern.com> writes:
} 
} > Unintended side-effect of all the race-condition-prevention work that
} > went on this summer.
} 
} Could this also be related to this glitch?

No, it couldn't, but that is an interesting one.

Re: Ctrl-c not working during correction with 5.1

[Bart Schaefer]

An additional comment ...

On Sep 2,  3:10pm, Christian Neukirchen wrote:
}
} zsh 5.1 (x86_64-unknown-linux-gnu)
} zsh-5.1-0-g11189c6
} % zsh -f
} juno% setopt NOALWAYSLASTPROMPT PROMPT_SUBST
} juno% PS1='$(echo foo)%# '
} foo% ls /usr/share/man/man1/<PRESS TAB HERE>
} zsh: do you wish to see all 2528 possibilities (1264 lines)? <PRESS ^C HERE>n
} $(echo ls /usr/share/man/man1/
} foo% 
} 
} Somehow the unevaluated PS1 is printed.

While attempting to reproduce this, I somehow managed to cause this to
kill the *parent* shell from which I started up "zsh -f".  I have no
good ideas how that could happen; no core files were produced.  But I
thought I would mention it, in case it indicates this is a more serious
problem than it appears.

In any event, it is reproducible.

Re: Ctrl-c not working during correction with 5.1

[Mikael Magnusson]

On Thu, Sep 3, 2015 at 4:32 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> An additional comment ...
>
> On Sep 2,  3:10pm, Christian Neukirchen wrote:
> }
> } zsh 5.1 (x86_64-unknown-linux-gnu)
> } zsh-5.1-0-g11189c6
> } % zsh -f
> } juno% setopt NOALWAYSLASTPROMPT PROMPT_SUBST
> } juno% PS1='$(echo foo)%# '
> } foo% ls /usr/share/man/man1/<PRESS TAB HERE>
> } zsh: do you wish to see all 2528 possibilities (1264 lines)? <PRESS ^C HERE>n
> } $(echo ls /usr/share/man/man1/
> } foo%
> }
> } Somehow the unevaluated PS1 is printed.
>
> While attempting to reproduce this, I somehow managed to cause this to
> kill the *parent* shell from which I started up "zsh -f".  I have no
> good ideas how that could happen; no core files were produced.  But I
> thought I would mention it, in case it indicates this is a more serious
> problem than it appears.
>
> In any event, it is reproducible.

This is at least two bugs,

zle -f
% bindkey 0 e
% e() exit
% zle -N e
% '
quote> 0

this prints the PS2 prompt indefinitely, ctrl-c is ignored and so is a
normal kill, I have to kill -9 from another shell to stop it. The
first happens in .7 and .8 too, but the ctrl-c being ignored is new, I
think.

-- 
Mikael Magnusson

Re: Ctrl-c not working during correction with 5.1

[Bart Schaefer]

On Sep 2,  7:32pm, Bart Schaefer wrote:
}
} In any event, it is reproducible.

And happens in 5.0.8 too, so it's at least not related to *recent*
signal handling changes.

Re: Ctrl-c not working during correction with 5.1

[Christian Neukirchen]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Sep 2,  7:32pm, Bart Schaefer wrote:
> }
> } In any event, it is reproducible.
>
> And happens in 5.0.8 too, so it's at least not related to *recent*
> signal handling changes.

Bisected it between 5.0.7 and 5.0.8 to

commit d067ebcacd55472f720b2765ec686a69b25c9a90
Author: Peter Stephenson <p.w.stephenson@ntlworld.com>
Date:   Sun Dec 7 16:24:19 2014 +0000

    33876: etc.: Separate errors and keyboards interrupts

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Ctrl-c not working during correction with 5.1

[Peter Stephenson]

On Wed, 2 Sep 2015 15:10:43 +0200
Christian Neukirchen <chneukirchen@gmail.com> wrote:
> zsh 5.1 (x86_64-unknown-linux-gnu)
> zsh-5.1-0-g11189c6
> % zsh -f
> juno% setopt NOALWAYSLASTPROMPT PROMPT_SUBST
> juno% PS1='$(echo foo)%# '
> foo% ls /usr/share/man/man1/<PRESS TAB HERE>
> zsh: do you wish to see all 2528 possibilities (1264 lines)? <PRESS ^C HERE>n
> $(echo ls /usr/share/man/man1/
> foo% 
> 
> Somehow the unevaluated PS1 is printed.

I see what's happened --- in the old days we reset the error flag which
cancelled both an error and interrupt; now it only cancels an error.
However, this is one of the small number of special places where we
don't want an interrupt to take us back to the original prompt --- it
should simply cancel the query and redraw the line.

I think if we do have an error or interrupt we should not be executing
the recursive zrefresh() that was causing the bad prompt; that would
have meant the interrupt took us back to a new prompt, which would
presumably be the correct behaviour if we *didn't* reset the interrupt.
I've added that, but I don't know anywhere the difference is visible
now.

pws

diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 78046fb..0c28c0a 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -1761,7 +1761,8 @@ singlelineout:
 	inlist = 1;
 	listmatches();
 	inlist = 0;
-	zrefresh();
+	if (!errflag)
+	    zrefresh();
     }
     if (showinglist == -1)
 	showinglist = nlnct;
diff --git a/Src/Zle/zle_utils.c b/Src/Zle/zle_utils.c
index d1d3206..9751f7a 100644
--- a/Src/Zle/zle_utils.c
+++ b/Src/Zle/zle_utils.c
@@ -1183,6 +1183,11 @@ getzlequery(void)
 
     /* get a character from the tty and interpret it */
     c = getfullchar(0);
+    /*
+     * We'll interpret an interruption here as only interrupting the
+     * query, not the line editor.
+     */
+    errflag &= ~ERRFLAG_INT;
     if (c == ZWC('\t'))
 	c = ZWC('y');
     else if (ZC_icntrl(c) || c == ZLEEOF)

PATCH: Builtin exit from inside ZLE widget

[Bart Schaefer]

On Sep 3,  5:00am, Mikael Magnusson wrote:
}
} % bindkey 0 e
} % e() exit
} % zle -N e
} % '
} quote> 0
} 
} this prints the PS2 prompt indefinitely, ctrl-c is ignored and so is a
} normal kill, I have to kill -9 from another shell to stop it.

This seems to be it:

diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index e610ae1..ec3d2c3 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -1276,7 +1276,7 @@ zleread(char **lp, char **rp, int flags, int context, char *init, char *finish)
     alarm(0);
 
     freeundo();
-    if (eofsent || errflag) {
+    if (eofsent || errflag || exit_pending) {
 	s = NULL;
     } else {
 	zleline[zlell++] = ZWC('\n');


There will be a final "unmatched '" reported in Mikael's specific example,
but quashing that is an exercise that can wait.