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]

>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