[Konsole-devel] 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]

>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