Re: Interrupting globs (Re: Something rotten in tar completion)

[Peter Stephenson <p.stephenson@samsung.com>]

On Fri, 5 Dec 2014 15:29:17 +0000
Peter Stephenson <p.stephenson@samsung.com> 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