[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/27/14 5:27 PM, Askar Safin wrote:

> Steps to reproduce: open konsole (with bash in it) and type Ctrl-Shift-X (this is shortcut for "Clear Scrollback and Reset" feature in konsole). What I see: the terminal clears and no prompt appear. What I expected: I expected prompt to appear.
> 
> This is upstream bug, and it is a regression. It appeared in bash 4.3, but in bash 4.2 there was no such bug.

This isn't exactly a bug.  It means that whatever secret mechanism konsole
uses to try to force a prompt redisplay uses a feature that changed between
bash-4.2 (readline-6.2) and bash-4.3.

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.

Since typing ^L at the prompt works, that's probably not what konsole uses.
If it were going to inject a character into the input to force a screen
clear, that would most likely be the one.

The other possibility is sending a signal.  The most likely candidate for
this is SIGWINCH, since readline reacts to it but it's not usually trapped.
If a user process had SIGWINCH trapped and konsole sent SIGWINCH in
response to a key sequence, we'd probably be seeing more bug reports.

SIGWINCH is not a great candidate for this, since readline sets things up
so that it doesn't interrupt system calls like read or write.  You don't
really want a SIGWINCH to interrupt reads or writes (especially writes)
even if you want to be notified of window size changes.  It's also
ignored by default, so if you're running something that doesn't install a
handler for it, you probably won't see anything but a blank screen after
a Ctrl-Shift-X.  The behavior you've observed, though, is consistent
with konsole sending bash a SIGWINCH and expecting it to handle the
signal immediately regardless of what it might be doing.

So it's probably SIGWINCH.  And since readline is waiting to read input,
and the SIGWINCH doesn't interrupt the read(2), there's nothing to tell
readline that it should redisplay the prompt.

Previous discussions of this topic:

http://lists.gnu.org/archive/html/bug-readline/2014-05/msg00005.html
http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00063.html

-- 
``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/