Bug#771244: 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
On 12/3/14, 9:52 AM, Askar Safin wrote: 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. Should long text line move when user changes size of terminal or no? So? Someone else already provided a suitable answer. Continuing this conversation is not productive; it's quickly reaching dead horse territory. You might want to check out the latest devel branch snapshot, though. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: 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
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: 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 wrote: 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? In my opinion the bug is in your expectations. You are asking the terminal emulator to clear the screen history. It does. This includes the prompt too. It does exactly what you asked. There isn't any surprise. You see the screen and know its state before the action and know whether it is displaying a prompt or whether it is currently running a program. You clear the screen. The screen is cleared. There is no prompt but you should know that in order to get a prompt all you need to do is hit Enter or Control-l and bash will print another prompt which will then be displayed. Or you could type in a command right then regardless. And of course it might be running a program and not at the bash prompt so whatever happens must work reasonably with any program. However you are expecting that after instructing the terminal to clear screen history that bash should emit a new prompt. I think that is an unreasonable expectation. There hasn't ever been a communication interface for doing such a thing. One could be created. But if so then that would be a *new* interface. Bob signature.asc Description: Digital signature
Bug#771244: 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
Doesn't seem like a bug to me. You asked your terminal emulator to clear the screen. It did so. Now you complain that it's too clean :) I understand how it may look confusing, but I don't think the term has much option here. Suppose that instead of the shell, you were executing something else (eg. reading a log file). What would be the right behavior there? Its only option is to clear its screen. If you know you were in a shell, and want the prompt to reappear, you only need to press enter after the reset. Best regards PS: While I agree that what you are considering a bug is not Debian-specific, I don't think you had enough data at bug submission time to ascertain that this was an upstream bug (specially not knowing which was the upstream provider). However, you did a good job describing the bug report itself. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: 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
On 11/28/14 10:34 AM, Askar Safin wrote: Doesn't seem like a bug to me. You asked your terminal emulator to clear the screen. It did so. Now you complain that it's too clean :) When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should work the same and it should clear scrollback additionally. bash 4.3 + konsole behavior is not OK for me, because I have to press Enter after Ctrl-Shift-X. :) This would make sense if the two operations did the same thing. I don't think they do; I think the Ctrl-Shift-X key sequence causes konsole to send SIGWINCH. I understand how it may look confusing, but I don't think the term has much option here. Suppose that instead of the shell, you were executing something else (eg. reading a log file). Yes, but this somehow worked before. And I press Ctrl-Shift-X in bash only. :) 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. Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: git bisect shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? Try looking at the devel branch. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: 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
On 11/28/14 8:17 PM, Askar Safin wrote: Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: git bisect shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? Try looking at the devel branch. Thanks. http://git.savannah.gnu.org/cgit/bash.git/commit/?id=f4f5e1c2b8fa4539e367e1f48774183d349184c5 in devel branch is commit which introduces this behavior (git bisect, again). But still this branch doesn't seem as real devel history. This is just weekly snapshots. Does bash have real SCM (non-git ones is OK)? Where is SCM you use for development? I use something local and home-grown that far predates git. The development history is a combination of the change log (CWRU/CWRU.chlog) and the git devel checkins. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: 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
Package: bash Version: 4.3 Severity: important Tags: upstream 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. My system is Debian Wheezy 7 amd64. My konsole version is 4:4.8.4-2 (upstream version: 2.8.4). And in fact, I don't know whatever this is bug in bash, in konsole, or this is not a bug at all. Also, this is upstream bug, so I CC'd bug-b...@gnu.org . And it is konsole-related, so I CC'd konsole-de...@kde.org . Also, the bug reproduces on both bash 4.2 and 4.2 in gnome-terminal with its reset feature. Also, I want to say that this is very confusing, hard-to-localize and hard-to-catch bug. At first, I noticed that Ctrl-Shift-X doesn't work as expected when I connect to some Ubuntu machine over ssh. At first I started to think this is ssh misconfiguration or some performance issue. Then I noticed that it reproduces with Ubuntu Trusty (with bash 4.3) remote machine and doesn't reproduce with Debian Wheezy (with bash 4.2) one. Then I understand that the bug is not related to ssh at all and this is just bash+konsole bug. So, because of this very confusing nature of the bug, I gave it priority important. == Askar Safin http://vk.com/safinaskar Kazan, Russia
