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

[Chet Ramey]

On 11/29/14 3:22 PM, Askar Safin wrote:
>> 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?

Please stop mischaracterizing the issue.  It's not a bug: it's a case of
konsole's mismatched expectations.  Since the mechanism it uses is not
documented, and relies on something in readline that is not documented, it
can't fairly be called a bug.

> Also, mc resizes when I resize terminal window in all terminals. So, bash 
> should move, too.

That's not quite relevant.  mc has apparently made the decision to allow
SIGWINCH to interrupt system calls.  Readline made a different decision.
Both made other implementation decisions based on that. What mc's behavior
proves is that it's possible to allow SIGWINCH to interrupt system calls.
We already knew that.

> 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?

Trying to put words in my mouth doesn't help you make a case.

> 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).

Did you understand anything about allowing SIGWINCH to interrupt system
calls?  That's the issue -- and not input system calls so much as output
system calls interrupting redisplay or completion.

(If you want an example of interrupted system calls causing weird errors,
look back in the bash mailing list archives for reports of SIGCHLD
interrupting open(2) and causing redirections to fail.)

There is a change involving pselect that may improve the situation, but
pselect is explicitly allowed to restart if a signal handler is installed
with the SA_RESTART flag, so we will have to see how portable that is.  I
understand that you only use Linux, and pselect might be ok there.  We
will see about other platforms.

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