On Fri 03 Feb 2023 at 23:59:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> > I don't know a lot about zsh, but I ran it, typed some letters, and
> > pressed Ctrl-U, and they were all erased as expected.
>
> But the point is multiline, as you did then:
>
On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> > 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 i
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 Lefev
On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> 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.
Ctrl-U is bound to "kill" at the terminal l
On 2023-01-24, Vincent Lefevre wrote:
>
>> In terms of accidents, you've just driven a car at a brick wall,
>> and it runs into it, as expected.
>
> No, with modern shells, bracketed paste is precisely there to avoid
> such kind of issues.
>
I thought it was designed to avoid formatting problems
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 li
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
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:
On Tue, Jan 24, 2023 at 10:34:01AM -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > > The xterm's pty's input buffer
On 2023-01-24 10:34:01 -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > > The xterm's pty's input buffer is full, and
On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 23:27:11 -0600, David Wright wrote:
> > On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-21 23:04:30 -0600, David Wright wrote:
> > >
> > > > In this case, if I paste the large file, I do
On Tue 24 Jan 2023 at 16:17:32 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 23:27:27 -0600, David Wright wrote:
> > On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > > > This might be a limitation of Linux's pty(7) subsyste
On Tue 24 Jan 2023 at 10:03:31 (+), Richmond wrote:
> Greg Wooledge wrote:
> > On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> >> I didn't test it for the reason I stated. I think it would be better for
> >> OP to test it as he won't do any more damage than he has already done.
> >
On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point
On 2023-01-24 10:03:31 +, Richmond wrote:
> No that wasn't the entire point of the thread. The OP didn't know the
> cause, it was presumed by David Wright that it was caused by the buffer
> filling up. But it could have been caused by some spurious character in
> the file, e.g. ctrl-s.
I know
On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.
They are actually not ignored, but delayed by the terminal em
On 2023-01-22 23:27:27 -0600, David Wright wrote:
> On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > > This might be a limitation of Linux's pty(7) subsystem. The xterm
> > > manpage mentions the following:
> > >
> > > ,
On 2023-01-22 23:27:11 -0600, David Wright wrote:
> On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> > On 2023-01-21 23:04:30 -0600, David Wright wrote:
> >
> > > In this case, if I paste the large file, I do see almost the start
> > > of the file (I seem to lose just the first lin
Greg Wooledge wrote:
> On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
>> I didn't test it for the reason I stated. I think it would be better for
>> OP to test it as he won't do any more damage than he has already done.
> Here's how you can reproduce the problem without having to worry
>
On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> I didn't test it for the reason I stated. I think it would be better for
> OP to test it as he won't do any more damage than he has already done.
Here's how you can reproduce the problem without having to worry
about execution of the past
On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> Greg Wooledge writes:
>
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point forward.
[...]
> I have come
Greg Wooledge writes:
> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.
>
> (Are people not actually *testing* these things before proposing them?)
I didn't tes
On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > This might be a limitation of Linux's pty(7) subsystem. The xterm
> > manpage mentions the following:
> >
> > ,
> > | BUGS
> > | Large pastes do not work on some systems
On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-21 23:04:30 -0600, David Wright wrote:
>
> > In this case, if I paste the large file, I do see almost the start
> > of the file (I seem to lose just the first line, which rolls off the
> > top), and ^C still works, returni
On Sun 22 Jan 2023 at 15:35:08 (-0500), Greg Wooledge wrote:
> On Sun, Jan 22, 2023 at 07:54:39PM +, Richmond wrote:
> > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > But nothing happens.
> > You could try pressing ctrl-z at this point to send the application into
> > backgroun
On 2023-01-21 23:04:30 -0600, David Wright wrote:
> The only suggestion I can give is that you start the applications
> concerned with &, so that you get the xterm prompt back.
Perhaps. For Emacs, this is more complex because it can also
run in the terminal, and the ultimate solution could be to
w
On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> This might be a limitation of Linux's pty(7) subsystem. The xterm
> manpage mentions the following:
>
> ,
> | BUGS
> | Large pastes do not work on some systems. This is not a bug in
> | xterm; it is a bug in the pseudo terminal dr
On Sun, Jan 22, 2023 at 07:54:39PM +, Richmond wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
> You could try pressing ctrl-z at this point to send the application into
> background.
It doesn't work, presumably for the same reason that Ctrl-C doesn't
Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
>
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk or xterm.
>
> 2. Paste a long text (e.g. t
On Sun 22 Jan 2023 at 07:16:47 (-0500), songbird wrote:
> Vincent Lefevre wrote:
> ...
> > Is there any way to avoid this issue?
>
> i'm not able to test either of these on your setup but
> perhaps you can?
>
> does it make any difference if you set the scrolling to
> unlimited in your termin
Vincent Lefevre wrote:
...
> Is there any way to avoid this issue?
i'm not able to test either of these on your setup but
perhaps you can?
does it make any difference if you set the scrolling to
unlimited in your terminal profile? (i have this option
in my terminal).
also have you ever us
On Sat 21 Jan 2023 at 23:04:30 (-0600), David Wright wrote:
> On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> > On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > > 3. Type Ctrl-C (one or several times) in th
On Sun 22 Jan 2023 at 18:59:54 (+1100), Keith Bainbridge wrote:
> Isn't it shft-ctrl-c to copy from x-term?
Just to clarify: I didn't try to copy /from/ an xterm, I pasted
/into/ the xterm, "accidently" on purpose of course.
I used my normal MO to source the large paste, ie I typed ^A^C
in Firef
On 2023-01-22 05:17 +0100, Vincent Lefevre wrote:
> On 2023-01-21 21:19:06 -0600, David Wright wrote:
>> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
>> > 3. Type Ctrl-C (one or several times) in the terminal.
>> > But nothing happens.
>>
>> I presume that's because the input buf
Sorry if this comes as a top post. I can't see the original text here
Isn't it shft-ctrl-c to copy from x-term?
On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > But nothing happens.
> >
> > I presume that's bec
On 2023-01-21 21:19:06 -0600, David Wright wrote:
> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
>
> I presume that's because the input buffer is already full, so
> you'd need what I think they ca
On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
>
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk o
The following issue is reproducible in several terminals, e.g. xterm
and GNOME Terminal, and several shells, e.g. bash and zsh.
1. From the shell in an X terminal emulator, run an X application
in foreground, e.g. emacs-gtk or xterm.
2. Paste a long text (e.g. the contents of /usr/share/doc/libc6
39 matches
Mail list logo
