zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Subject: Re: Functions registered with zle -F stop being run after a job finishes
Date: Sat, 23 Mar 2019 18:30:30 +0000	[thread overview]
Message-ID: <681eee2a4531f27e3b553eeb18ec4e5864858b15.camel@ntlworld.com> (raw)
In-Reply-To: <CAN=4vMp8fkVKWXKXop7WjEWJYxhfkK3nEq0C4V8rj76Gs2XsXg@mail.gmail.com>

> tl;dr: There appears to be a bug in zsh. When a background job finishes,
> functions registered with zle -F stop running until the user presses a key
> (say, [enter] or [esc]) or the shell receives a signal (any signal at all).

It's going to be something like the following.  Note I haven't tried
this, except to confirm it compiles, but it looks like you've got a
reliable way of provoking this, and this should give you enough to go on
--- it's 99% certain the problem lies in that for (;;) loop surrounding
the code patched here.

The story is that we try to make sure errors on the -F file descriptors
don't mess up the editor.  The errtry flag exists to say they look
suspect, so we'll try to ensure the user can continue editing even so.
In your case, however, the return value from poll (probably) or select
(in the unlikely event you don't have poll) is simply indicating the
call was interrupted, so we can carry on trying.

Not 100% sure if a "continue" or simply falling through is better here
--- falling through might be better to get any remaining timeout fixed
up, though that doesn't look like a problem in your case, but as the
poll / select didn't give us anything useful it's otherwise better to
continue.

Hope this gives you enough pointers.
pws

diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index 71930f76b..8de8e0121 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -632,7 +632,13 @@ raw_getbyte(long do_keytmout, char *cptr, int full)
 	     * with all fds, then try unsetting the special ones.
 	     */
 	    if (selret < 0 && !errtry) {
-		errtry = 1;
+		if (errno == EINTR) {
+		    /* Continue after interrupt */
+		    errflag &= ~ERRFLAG_INT;
+		} else {
+		    /* Don't trust special FDs */
+		    errtry = 1;
+		}
 		continue;
 	    }
 	    if (selret == 0) {



  reply	other threads:[~2019-03-23 18:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-23 13:55 Roman Perepelitsa
2019-03-23 18:30 ` Peter Stephenson [this message]
2019-03-27 19:01   ` Peter Stephenson
2019-03-28 10:31     ` Roman Perepelitsa
2019-03-25 22:11 ` Roman Perepelitsa
2019-03-26  9:22   ` Peter Stephenson
2019-03-26  9:36     ` Roman Perepelitsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=681eee2a4531f27e3b553eeb18ec4e5864858b15.camel@ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).