[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole
From: |
Askar Safin |
Subject: |
Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3 |
Date: |
Sat, 29 Nov 2014 23:22:38 +0300 |
>No. You have missed the point. The point is that the secret mechanism
>that konsole used to use no longer works. It didn't rely on documented
>behavior; it relied on a side effect of the (flawed) readline-6.2
>implementation. It can't really be called a bug.
Okey, so, Chet, what will you say about resizing bug? Is this a bug? At this
moment I doesn't ask where (readline or konsole) this bug resides. I'm just
asking: is this a bug? Or "long line doesn't move on resize" is intended
behavior?
Also, mc resizes when I resize terminal window in all terminals. So, bash
should move, too.
Then, if you agree this is a bug, where should it fixed? You think in konsole,
right? So, you think that konsole should be aware of some readline internals
and should redisplay readline prompt itself? Well, let's suppose this. But what
about mc?
If I will follow your logic, it seems that mc should not redisplay itself in
SIGWINCH handler (because it should not call too many functions in handlers)
and so we have two possibilities:
1) Terminal should redisplay mc itself (this is impossible)
2) mc should not redisplay itself on SIGWINCH, nor terminal should do this. So,
mc just should not resize (and user will be angry)
mc somehow was able to redisplay itself on SIGWINCH, so why readline (which is
smaller program) cannot? (And I don't ask you to fix this bug now, if you will
say "OK, it should be fixed, but I currently don't have time", this will be
completely OK for me.)
Yes, I understand, handlers, blah-blah. readline should not perform a lot of
actions in SIGWINCH handler, so, they are deferred until read() exits. But mc
has no such problems. And ssh client has no such problems (and so, it is able
to pass SIGWINCH to remote program, for example, to remote mc).
>Further complicating things is the fact that there is not any portable
>way to specify that SIGWINCH should interrupt system calls.
(from http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00070.html )
Well, let's specify that SIGWINCH should interrupt syscalls at least on archs
where it is supposed to use interactive resizeable terminals. :) I don't think
that someone use interactive terminal and resize it on some embedded device.
(On GNU/Linux SIGWINCH interrupts read() by default, I tested this.) So, you
can perform some compile-test. If you can make SIGWINCH to interrupt read()
(for example, on GNU/Linux), then let's do it, if no - so, no.
(Yes, there is still a problem: you may want to connect via ssh from some
normal desktop OS (GNU/Linux, Mac OS X, WIndows) to some obscure embedded
device. And in this case SIGWINCH will not work. But this a very special case,
so this is OK.)
Now immediate resizing just doesn't work (at least in konsole). If it will work
at least on some platforms (GNU/Linux) this will be very good.
And now I have read threads you pointed.
>I have to evaluate the possible consequences of
>doing that, since, as I said, it leads to hard-to-reproduce problems.
So, again, do you acknowledge that there is a bug in bash, which eventually
should be fixed? (And again, I don't ask to fix it now.)
Also, I wrote small C program to test what method terminal use to force program
resizing: http://paste.debian.net/134231 . Chet, you may test this program on
Mac OS. I tested it with bash 4.2, bash 4.3, Debian's gnome-terminal 2.30.2-1,
Debian's konsole 4:4.4.5-2 (upstream version 2.4.5) and got the following
results:
What terminals send to program?
| "clear and reset" | resize
gnome-terminal | nothing | SIGWINCH
konsole | SIGWINCH | SIGWINCH
What behavior seems to me as "good"? :)
| "clear and reset" | resize
gnome-terminal + bash 4.2 | bad | good
gnome-terminal + bash 4.3 | bad | bad
konsole + bash 4.2 | good | good
konsole + bash 4.3 | bad | bad
(And this gnome-terminal may be too old, i. e. Pádraig Brady just reported his
gnome-terminal works, he probably uses newer version.)
==
Askar Safin
http://vk.com/safinaskar
Kazan, Russia
Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Chet Ramey, 2014/11/28
- Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Askar Safin, 2014/11/28
- Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Chet Ramey, 2014/11/28
- Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3,
Askar Safin <=
- Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Bob Proulx, 2014/11/29
- Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Chet Ramey, 2014/11/30
- Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Askar Safin, 2014/11/30
- Re: Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3, Ángel González, 2014/11/30