[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

[Chet Ramey]

On 11/28/14 5:38 PM, Askar Safin wrote:
>> There are only a couple of ways to do this, so even though the mechanism
>> konsole uses is undocumented, we can try to figure it out.  There are two
>> possibilities: inject a character into the input stream, or send a signal
>> to the foreground process group.
> I tested this. This is not some symbol in input stream (tested using "stty raw -echo; cat > /tmp/log"). And this is signal 28, i. e. SIGWINCH (on Debian GNU/Linux amd64, tested using small C program). Also, a small test C program, which uses readline (Debian version 6.2+dfsg-0.1) works as I expect.
> 
> So, yes, this is not bash+konsole bug, this is readline+konsole bug.

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.


>> There is a better explanation in one of the threads I referenced in my
>> previous message, but here's the short story: readline has always set
>> SIGWINCH to restart system calls. It would redraw the prompt upon receipt
>> of a SIGWINCH in previous versions because it (incorrectly) executed that
>> code in a signal handler context. Cleaning up the code so it didn't try
>> to execute arbitrary code in signal handlers was one of the big changes
>> between bash-4.2/readline-6.2 and bash-4.3/readline-6.3.
> So, is this possible to restore old behavior in bash-4.3/readline-6.3 preserving "clean" and "right" code?

Not in its current form, no.  If you read the threads I referred to in
the previous message, you will see this message, which lays out the
problem pretty clearly:

http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00070.html

In another message, you'll find:

"You have to think about the difference between a signal that
interrupts a system call, like SIGALRM, and a signal like SIGWINCH that
does not.  If the system call isn't interrupted, readline doesn't have an
opportunity to do anything until it returns.  I can look at changing
readline so that a SIGWINCH interrupts system calls, but I will have to
look at the code more before doing it.  Having system calls interrupted
in unexpected places leads to hard-to-find problems, and SIGWINCH is
supposed to be transparent.  I will play around with it."

While there have been some interesting ideas proposed, the easiest way
to make this sort of dyamism possible is to keep SIGWINCH from restarting
system calls by default.  I have to evaluate the possible consequences of
doing that, since, as I said, it leads to hard-to-reproduce problems.

> ATTENTION! Now I want to report some REAL BUG! When I change konsole size with some long text line typed in bash 4.2 buffer, text moves. With bash 4.3 it doesn't move. :)
> Yes, I know, nobody uses Ctrl-Shift-X except for me, so, you think this Ctrl-Shift-X-bug isn't worth fixing. But everybody resize his terminal window, so now I found real bug, ahaha! :)
> Reproduces using 4.3-11 from Debian and doesn't reproduce using 4.2+dfsg-0.1+deb7u3 from Debian. And thank you, Chet for the idea. :)

You have not identified a bug in readline, you have identified a bug in
konsole.  konsole apparently expects that sending a stream of SIGWINCHes
to the foreground process is enough to force redisplay.  Other terminal
emulators, like Mac OS X Terminal, manage to make redisplay work in this
case.

chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/