zsh-workers
 help / color / mirror / code / Atom feed
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:36:02 +0100	[thread overview]
Message-ID: <CAHYJk3TCJYd6Oy5rgSd4YUoL4aSgYJcDTJ5Q1DUBxCGvLMhr4Q@mail.gmail.com> (raw)
In-Reply-To: <20141205220717.2f86bdd2@pws-pc.ntlworld.com>

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
}

The git branch is actually git brunch, which is git aliased to
brunch  -- alias for '!git branch -v|sed -e 's/t/ /g' -e 's/(.{'$((
$(tput cols) - 1 ))'})
There's no .tdldb in that directory either, but including it unmodified anyway.

-- 
Mikael Magnusson


  parent reply	other threads:[~2014-12-06  0:36 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 [this message]
2014-12-06  0:40                       ` Mikael Magnusson
2014-12-06 22:31                         ` Bart Schaefer
2014-12-06  0:52                       ` Mikael Magnusson
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=CAHYJk3TCJYd6Oy5rgSd4YUoL4aSgYJcDTJ5Q1DUBxCGvLMhr4Q@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).