From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22301 invoked by alias); 7 Dec 2014 04:45:02 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33897 Received: (qmail 5137 invoked from network); 7 Dec 2014 04:44:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=F/vgrRlI c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=mvU7be_kCnLSJ1WxF_wA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141206204503.ZM15491@torch.brasslantern.com> Date: Sat, 06 Dec 2014 20:45:03 -0800 In-reply-to: Comments: In reply to Mikael Magnusson "Re: Interrupting globs (Re: Something rotten in tar completion)" (Dec 7, 2:42am) References: <20141202155452.647182b4@pwslap01u.europe.root.pri> <141202084858.ZM31517@torch.brasslantern.com> <20141202172654.30e7d380@pwslap01u.europe.root.pri> <141204085606.ZM9146@torch.brasslantern.com> <20141204171226.301e9d2c@pwslap01u.europe.root.pri> <141205002023.ZM19736@torch.brasslantern.com> <20141205145054.655a2f70@pwslap01u.europe.root.pri> <141205100632.ZM508@torch.brasslantern.com> <20141205181330.2b458b46@pwslap01u.europe.root.pri> <20141205203417.2bc66b7b@pws-pc.ntlworld.com> <20141205220717.2f86bdd2@pws-pc.ntlworld.com> <141206094849.ZM1787@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Interrupting globs (Re: Something rotten in tar completion) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Trimming some context ... still a lot, tho ... On Dec 7, 2:42am, Mikael Magnusson wrote: } Subject: Re: Interrupting globs (Re: Something rotten in tar completion) } } > } > Ah, I think I understand what's happening now. Prior to the patch, } > } > pressing ctrl-c would abort out of chpwd() completely, but now it just } > } > aborts whichever single command is running. } > } > } Another difference: the menu completion listing could previously be } > } aborted with ctrl-c and keep the command line. It now closes the } > } listing and aborts the command line. Additionally, with menu } > } selection, you could previously ctrl-c out of selection and get to the } > } menu, ctrl-c that again, and still have the command line. Now you just } > } go straight from selection to a new empty command line. } > } } @@ -883,7 +883,7 @@ getbyte(long do_keytmout, int *timeout) } die = 0; } if (!errflag && !retflag && !breaks && !exit_pending) } continue; } - errflag = 0; } + errflag &= ~ERRFLAG_ERROR; } breaks = obreaks; } errno = old_errno; } return lastchar = EOF; } } Undoing only this hunk fixes this for me. I can't find anything that } stops being interruptible but I only tried for a minute. This probably indicates that one or more of the callers of getbyte() (or someone even earlier in the stack) need to clear user interrupts, rather than that they should be cleared here. It makes some kind of sense that code which could previously assume that errflag had been completely cleared, might after this patch need to explicitly handle interrupt conditions. I'm not sure how we find all such places, though. Some of them might not even test errflag, at present; many might do so. } @@ -1444,12 +1444,7 @@ zwaitjob(int job, int wait_cmd) } restore_queue_signals(q); } return 128 + last_signal; } } } - /* Commenting this out makes ^C-ing a job started by a function } - stop the whole function again. But I guess it will stop } - something else from working properly, we have to find out } - what this might be. --oberon } - } - errflag = 0; */ } + errflag &= ~ERRFLAG_ERROR; } if (subsh) { } killjb(jn, SIGCONT); } jn->stat &= ~STAT_STOPPED; } } And commenting that line back out fixes my chpwd() hook ctrl-c thing. } (or changing it to errflag &= ~ERRFLAG_INT; but I have no idea if that } makes any sense). Both things fit with Oberon's comment, actually. Based on the comment, what we do NOT want to do there is clear ERRFLAG_INT. (That comment has been there for more than 25 years, so if something else were going to have stopped working properly I think we'd have found out by now.) Whether clearing internal errors at that point is also necessary is a fresh mystery. I guess I'd try leaving it &= ~ERRFLAG_INT for a while.