Re: Ctrl-C ignored after pasting a long text in an X terminal emulator
On Thu 26 Jan 2023 at 18:34:24 (+0100), Vincent Lefevre wrote:
> On 2023-01-25 14:08:07 -0600, David Wright wrote:
> > On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > > > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> > > [...]
> > > > > For instance, if I paste the following 3 lines
> > > > >
> > > > > foo1
> > > > > foo2
> > > > > foo3
> > > > >
> > > > > in dash, I get:
> > > > >
> > > > > $ foo1
> > > > > foo2
> > > > > foo3
> > > > > sh: 1: foo1: not found
> > > > > $ sh: 2: foo2: not found
> > > > > $ sh: 3: foo3: not found
> > > > > $
> > > > >
> > > > > Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> > > > > and the 3 commands have already been executed.
> > > >
> > > > Well, sure, you've pasted lines into a shell, and they get executed.
> > > > I don't think you want to prevent that.
> > >
> > > With bracketed paste, the lines remains in the command line at the
> > > prompt until the user has typed the [Enter] key to run them. So the
> > > user can also type Ctrl-C to prevent any execution (or he can edit
> > > the command).
> >
> > You're preaching to the converted; see
> > https://lists.debian.org/debian-user/2023/01/msg00562.html
> > two posts back.
>
> About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> not really usable in zsh to erase long pastes (unless one changes
> the default bindings). But Ctrl-C is fine in zsh.
So it's just a case of choosing the appropriate workaround for
your release/terminal/shell. (I suppose I should add: in whatever
combination.) Will wayland matter? :)
> > My comment was with respect to your point 2, which was about
> > non-bracketed paste, and which was snipped off the top of your post.
> >
> > BTW are you implying that dash does bracketed paste? I didn't know that.
>
> No, the opposite: I'm showing above that dash does not support
> bracketed paste. This means that running an X application in
> background with "&" would not solve the problem with dash, and this
> would actually be worse with short pastes (which are cancellable
> with Ctrl-C or Ctrl-Z when an application is running in foreground).
> I normally don't run X application from dash (which I use mainly for
> testing shell behavior), but this doesn't mean that this will never
> occur.
Ditto as above. Sorry & doesn't work for you. I guess there's
a point at which you run out of options for the computer to
"automatically" work around the effects of your actions, and you
just have to put up with negative consequences of your mistakes.
Cheers,
David.
Reply to: