[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole sto

From: Chet Ramey
Subject: 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
Date: Fri, 28 Nov 2014 20:44:47 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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:


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]