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

[Bart Schaefer <schaefer@brasslantern.com>]

Whew, caught up I think ...

On Dec 5, 10:07pm, Peter Stephenson wrote:
}
} The general strategy is to use the bit ERRFLAG_ERROR for internal
} failures and ERRFLAG_INT for user interrupts.  There are only two
} cases of the latter: on an untrapped SIGINT, the obvious case, and also
} on a trapped SIGINT or SIGQUIT where we've been told to behave as if the
} trap didn't trap the error condition.  That's straightforward for
} SIGINT, less so for SIGQUIT but I took my cue from the fact that Bart
} thought it worthwhile trapping SIGQUIT as an interactive "no, I really
} mean abort" in completion, which implies that if we trap it we want it
} to work at least as well as SIGINT.

I would say that INT should be "less drastic" than QUIT.  For example
in the cases Mikael mentions in subsequent messages -- stopping menu
selection, etc. -- the ideal thing would be if QUIT broke all the way
out to a new command line while INT backed up only one level.  However,
I'm not sure how QUIT behaved before (or even whether it is enabled as
a keyboard-generated signal, since we don't have a handler for it) --
I trapped both INT and QUIT there because they both *could* come from
the keyboard, if stty were configured for it.

} Correspondingly, most of the time only the ERRFLAG_ERROR bit gets
} reset.  ERRFLAG_INT gets reset [...]
} 
} - at the start of zleread, so we can read the next thing to do whatever
} just happened.  I'm not sure this is particularly useful

But the situation before this patch is the same, is it not?

} - when we just finished completion.  This is needed so that the cases
} that got this whole business kicked off behave as now (but more
} reliably) --- a ^C gets you back to the command line, but the command
} line is not trashed as it would be if you ^Ced outside completion (try
} it if you're confused).  There's a race here, but it's no worse than it
} ever was.

I think Mikael's example shows there are sub-cases of completion where we
need to add clearing of interrupts, rather than backing all the way out
of completion.

} To ensure ERRFLAG_INT doesn't get reset unnecessarily there are a number
} of cases where restoring errflag to a previously saved value keeps the
} ERRFLAG_INT bit if it got set in the meanwhile.  I hope the rationale
} here is obvious --- the ERRFLAG_ERROR is an internal state that needs
} resetting, the ERRFLAG_INT an asynchronous condition where the user
} doesn't care what the internal state is.

Are there any cases where errflag is unconditionally restored, or did you
change all such save/restore pairs?

Either the ternary is irrelevant here, or the "if (errflag)" is:

} @@ -2691,7 +2702,7 @@ execcmd(Estate state, int input, int output, int how, int last1)
}  		    if (varspc)
}  			addvars(state, varspc, 0);
}  		    if (errflag)
} -			lastval = errflag;
} +			lastval = errflag ? 1 : 0;
}  		    else
}  			lastval = cmdoutval;
}  		    if (isset(XTRACE)) {