From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <p.w.stephenson@ntlworld.com>
Cc: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: Interrupting globs (Re: Something rotten in tar completion)
Date: Sat, 6 Dec 2014 01:52:43 +0100 [thread overview]
Message-ID: <CAHYJk3RfWRCH4yNbe+9JCbO0C99miB9g4juLWNKcs=PSnYyEZg@mail.gmail.com> (raw)
In-Reply-To: <CAHYJk3TCJYd6Oy5rgSd4YUoL4aSgYJcDTJ5Q1DUBxCGvLMhr4Q@mail.gmail.com>
On Sat, Dec 6, 2014 at 1:36 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On Fri, Dec 5, 2014 at 11:07 PM, Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
>> On Fri, 5 Dec 2014 20:34:17 +0000
>> Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>>> On the other problem I came up with, that eval is resetting errflag even
>>> if you've interrupted: how about the following? Add a bit to errflag to
>>> signify that the user interrupted the shell rather than that some
>>> internal error (e.g. syntax) occurred. Only reset this new bit in a few
>>> key places: the main command loop when executing, the top of ZLE when
>>> editing being the obvious places. Convert other "errflag = 0"
>>> assignments case by case so that they just remove bit 0; then eval can
>>> continue to do its job of acting as a sandbox but without screwing up
>>> the behaviour of interrupts. I think doing that is fairly mechanical
>>> and it achieves what's needed without compromising anything else.
>>
>> Here's my first go; it does seem to do what I want, and as a by-product
>> fixes all the little race conditions we've always had that meant you
>> couldn't interrupt chunks of code that were executed in any kind of
>> sandbox because the condition got reset afterwards. I think a few of
>> these have been annoying me over the years.
>>
>> 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.
>>
>> Correspondingly, most of the time only the ERRFLAG_ERROR bit gets
>> reset. ERRFLAG_INT gets reset only in the following cases:
>>
>> - in the main command loop. This is what causes the shell not to exit but
>> instead go back to the main command loop when you ^C a command.
>>
>> - 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 since
>> in this case you'd typically expect the previous condition to have
>> occurred and it could mean e.g. you ignore an interrupt that
>> occurred just before a "vared".
>>
>> - 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.
>>
>> 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.
>>
>> By the way, looking at the patch below you might wonder if it wouldn't
>> be more efficient to add a separate flag for interrupt error conditions
>> to test. It wouldn't --- there are many more cases where errflag is
>> tested than when it is set, not affected by the patch below.
>>
>> I suspect we'll just have to try this out and see how it works.
>
> This seems to work well for me in the cases you talked about, but I
> quickly noticed one surprising problem. I have some stuff in my
> chpwd() hook to show git branches and stuff, and these used to be
> interruptible by ctrl-c (the commands are very fast with hot cache,
> but can be somewhat painful with cold cache, like 5-10 seconds delay).
> With the patch, I cannot interrupt them (sometimes?).
>
> chpwd () {
> stty -echo >&/dev/null
> test -f .tdldb && tdll -1 >&2
> test -d .git && {
> git branch
> test -d .git/svn && {
> echo -n r
> git svn find-rev master
> }
> git name-rev HEAD
> git describe --tags HEAD 2> /dev/null
> } >&2
> if [[ "$_NONOCDLS" = 1 ]]
> then
> ls $LS_OPTIONS >&2
> fi
> }
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. Since I have three git
commands in there, I now need to press ctrl-c three times to get back
to the prompt quickly. (I would like it to only require one).
--
Mikael Magnusson
next prev parent reply other threads:[~2014-12-06 0:52 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 15:54 Something rotten in tar completion Peter Stephenson
2014-12-02 16:48 ` Bart Schaefer
2014-12-02 17:26 ` Peter Stephenson
2014-12-04 16:56 ` Bart Schaefer
2014-12-04 17:12 ` Peter Stephenson
2014-12-05 8:20 ` Interrupting globs (Re: Something rotten in tar completion) Bart Schaefer
2014-12-05 14:17 ` Jérémie Roquet
2014-12-06 21:50 ` Bart Schaefer
2014-12-06 22:15 ` Bart Schaefer
2014-12-05 14:50 ` Peter Stephenson
2014-12-05 15:14 ` Jérémie Roquet
[not found] ` <22084.1417791853@thecus.kiddle.eu>
2014-12-05 15:29 ` Peter Stephenson
2014-12-05 17:03 ` Peter Stephenson
2014-12-05 17:53 ` Peter Stephenson
2014-12-05 18:06 ` Bart Schaefer
2014-12-05 18:13 ` Peter Stephenson
2014-12-05 20:34 ` Peter Stephenson
2014-12-05 22:07 ` Peter Stephenson
2014-12-06 0:32 ` Ray Andrews
2014-12-06 22:27 ` Bart Schaefer
2014-12-06 22:57 ` Ray Andrews
2014-12-06 0:36 ` Mikael Magnusson
2014-12-06 0:40 ` Mikael Magnusson
2014-12-06 22:31 ` Bart Schaefer
2014-12-06 0:52 ` Mikael Magnusson [this message]
2014-12-06 11:49 ` Mikael Magnusson
2014-12-06 17:48 ` Bart Schaefer
2014-12-07 1:42 ` Mikael Magnusson
2014-12-07 4:45 ` Bart Schaefer
2014-12-07 5:04 ` Bart Schaefer
2014-12-07 17:39 ` Peter Stephenson
2014-12-07 22:59 ` Mikael Magnusson
2014-12-07 5:18 ` Bart Schaefer
2014-12-07 17:07 ` Peter Stephenson
2014-12-07 17:19 ` Peter Stephenson
2014-12-08 11:18 ` Peter Stephenson
2014-12-08 12:43 ` Mikael Magnusson
2014-12-08 13:03 ` Peter Stephenson
2014-12-08 15:51 ` Mikael Magnusson
2014-12-08 16:41 ` Bart Schaefer
2014-12-07 17:37 ` Oliver Kiddle
2014-12-07 18:18 ` Peter Stephenson
2014-12-07 18:34 ` Bart Schaefer
2014-12-07 18:59 ` Peter Stephenson
2014-12-07 19:58 ` Bart Schaefer
2014-12-08 10:01 ` Peter Stephenson
2014-12-07 20:20 ` Peter Stephenson
2014-12-07 20:54 ` Bart Schaefer
2014-12-07 20:03 ` Peter Stephenson
2014-12-07 5:59 ` Bart Schaefer
2014-12-07 7:15 ` Mikael Magnusson
2014-12-07 16:21 ` Peter Stephenson
2014-12-07 23:01 ` Interrupts in completion, traps in _main_complete Bart Schaefer
2014-12-08 20:27 ` Peter Stephenson
2014-12-09 4:43 ` Bart Schaefer
2014-12-09 11:26 ` Peter Stephenson
2014-12-09 11:50 ` Peter Stephenson
2014-12-09 21:09 ` Peter Stephenson
2014-12-10 10:02 ` interrupt_abort incorporation Peter Stephenson
2014-12-11 10:00 ` Peter Stephenson
2014-12-04 17:24 ` Something rotten in tar completion Bart Schaefer
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='CAHYJk3RfWRCH4yNbe+9JCbO0C99miB9g4juLWNKcs=PSnYyEZg@mail.gmail.com' \
--to=mikachu@gmail.com \
--cc=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).