From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18303 invoked by alias); 5 Dec 2014 17:03:57 -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: 33864 Received: (qmail 13403 invoked from network); 5 Dec 2014 17:03:55 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f5-b7fc86d0000066b7-03-5481e578c58e Date: Fri, 05 Dec 2014 17:03:48 +0000 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Interrupting globs (Re: Something rotten in tar completion) Message-id: <20141205170348.1c356c5a@pwslap01u.europe.root.pri> In-reply-to: <20141205152917.7f9efe3c@pwslap01u.europe.root.pri> 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> <22084.1417791853@thecus.kiddle.eu> <20141205152917.7f9efe3c@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsVy+t/xq7oVTxtDDH48ZrE42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGS1HbAq+8lRMOLOEpYFxClcXIyeHhICJxIeDXxkhbDGJC/fW s3UxcnEICSxllJi+YSoLhLOESWL7jKuMEM42Ronnf+8wgbSwCKhKPPl+F8xmEzCUmLppNlAR B4eIgLZE+0cxkLCwgIfEgS1/WEBsXgF7iYPt88C2cQo4SNx4fRFq5hlmieftZ9hBEvwC+hJX /35igjjJXmLmlTOMEM2CEj8m3wMbxCygJbF5WxMrhC0vsXnNW2YQW0hAXeLG3d3sExiFZiFp mYWkZRaSlgWMzKsYRVNLkwuKk9JzjfSKE3OLS/PS9ZLzczcxQoL26w7GpcesDjEKcDAq8fD+ iGsMEWJNLCuuzD3EKMHBrCTCmzwbKMSbklhZlVqUH19UmpNafIiRiYNTqoGx83u0RObuhXsP F13a9ls9a+5Mu6iC45ekdTW6pfrfy6pXOF1Q1JnGf/rIuwfvHuz5MHXCIeYqAcloToXA+y3h C58u21j94G14jm/vrF4RZ7auDve3bVO+pv69l+2/4E3ug8ilwcaTeFtNi5nrJL1zHoX5drV0 +Oumqq/Y9eKyeu/8m5Fzn3MpsRRnJBpqMRcVJwIArNoGjzgCAAA= On Fri, 5 Dec 2014 15:29:17 +0000 Peter Stephenson wrote: > Fixing the TRAPINT puts back the ZLE info output by the trap. However, > it doesn't fix the interrupts --- it's nothing like as bad as it was > with the wrong sort of trap, but I still need to ^C a few times to get > back to editing. It might be once per completer. (It's sort of vaguely > useful that I can ^C to get to the next completer but it's a bit > confusing and this obviously isn't the way it's designed.) I think this is because eval is setting errflag unconditionally to 0. Is that really correct? Usually if you want to avoid a gross error in a shell you use a subshell, not an eval (though other sorts of scripting language do use eval for this sort of protection). Certainly removing that seems to make interrupts much smoother; however, it looks like the test system depends on the eval behaviour. But surely this means it's not actually possible to get interrupts to work properly? Could it be made conditional on being interactive (below, which does what I want in the cases I've tried)? Or should we be setting a different flag / a different value of errflag if we received an interrupt that should cause an abort? BTW I'll commit the trap fix immediately. diff --git a/Src/builtin.c b/Src/builtin.c index c2af51f..f28b634 100644 --- a/Src/builtin.c +++ b/Src/builtin.c @@ -5074,7 +5074,8 @@ eval(char **argv) if (fpushed) funcstack = funcstack->prev; - errflag = 0; + if (errflag && !isset(INTERACTIVE)) + errflag = 0; scriptname = oscriptname; ineval = oineval; pws