Re[2]: 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
>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. It works! Thanks a lot. Bug seems to be fixed in 2bfa477ae8878e21c0b15b5d66099c4c16899c0a in branch devel of git://git.sv.gnu.org/bash.git Bug in readline alone seems to be fixed, too (tested using small C program on top of readline). Thanks again, Chet, you are nice. ^_^ As well as I know bugs in Debian bug tracker should not be closed until fixed version will be uploaded to Debian. So, I will not close the bug (right?). == Askar Safin http://vk.com/safinaskar Kazan, Russia
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
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/
Re[3]: 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
>> 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? Askar
Re: Re[2]: 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: > > 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? > > Askar It's the same issue: when SIGWINCH is received, read() is restarted automatically (ERESTARTSYS) and thus bash isn't calling the ioctl(0, TIOCGWINSZ, ) until readline receives the next character, at which point the full line is rewritten. (and yes, it seems desirable not to wait for next character)
Re[2]: 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
> 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? Askar
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
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/
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
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
Re[2]: 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
>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? Also, mc resizes when I resize terminal window in all terminals. So, bash should move, too. 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? If I will follow your logic, it seems that mc should not redisplay itself in SIGWINCH handler (because it should not call too many functions in handlers) and so we have two possibilities: 1) Terminal should redisplay mc itself (this is impossible) 2) mc should not redisplay itself on SIGWINCH, nor terminal should do this. So, mc just should not resize (and user will be angry) mc somehow was able to redisplay itself on SIGWINCH, so why readline (which is smaller program) cannot? (And I don't ask you to fix this bug now, if you will say "OK, it should be fixed, but I currently don't have time", this will be completely OK for me.) 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). >Further complicating things is the fact that there is not any portable >way to specify that SIGWINCH should interrupt system calls. (from http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00070.html ) Well, let's specify that SIGWINCH should interrupt syscalls at least on archs where it is supposed to use interactive resizeable terminals. :) I don't think that someone use interactive terminal and resize it on some embedded device. (On GNU/Linux SIGWINCH interrupts read() by default, I tested this.) So, you can perform some compile-test. If you can make SIGWINCH to interrupt read() (for example, on GNU/Linux), then let's do it, if no - so, no. (Yes, there is still a problem: you may want to connect via ssh from some normal desktop OS (GNU/Linux, Mac OS X, WIndows) to some obscure embedded device. And in this case SIGWINCH will not work. But this a very special case, so this is OK.) Now immediate resizing just doesn't work (at least in konsole). If it will work at least on some platforms (GNU/Linux) this will be very good. And now I have read threads you pointed. >I have to evaluate the possible consequences of >doing that, since, as I said, it leads to hard-to-reproduce problems. So, again, do you acknowledge that there is a bug in bash, which eventually should be fixed? (And again, I don't ask to fix it now.) Also, I wrote small C program to test what method terminal use to force program resizing: http://paste.debian.net/134231 . Chet, you may test this program on Mac OS. I tested it with bash 4.2, bash 4.3, Debian's gnome-terminal 2.30.2-1, Debian's konsole 4:4.4.5-2 (upstream version 2.4.5) and got the following results: What terminals send to program? | "clear and reset" | resize gnome-terminal | nothing | SIGWINCH konsole| SIGWINCH | SIGWINCH What behavior seems to me as "good"? :) | "clear and reset" | resize gnome-terminal + bash 4.2 | bad | good gnome-terminal + bash 4.3 | bad | bad konsole + bash 4.2| good | good konsole + bash 4.3| bad | bad (And this gnome-terminal may be too old, i. e. Pádraig Brady just reported his gnome-terminal works, he probably uses newer version.) == Askar Safin http://vk.com/safinaskar Kazan, Russia
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
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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
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/
Re[2]: 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
>> 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? == Askar Safin
Re[2]: 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
>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. >Since typing ^L at the prompt works, that's probably not what konsole uses. Yes, ^L works. Also, konsole 2.8.4 (upstream version, default in wheezy) (this is version I use) uses Ctrl-Shift-X as default shortcut for "Clear Scrollback and Reset" and konsole 2.14.2 (upstream version, default in sid as on today) uses Ctrl-Shift-K. >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 still want Ctrl-Shift-X to work as in 4.2. ^_^ >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? 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. :) == Askar Safin http://vk.com/safinaskar Kazan, Russia
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
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/
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
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/msg5.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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re[2]: 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" :) 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. :) >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. :) >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. :) Reproduced with bash 4.3 built from upstream sources. And yes, konsole was from Debian. 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? == Askar Safin http://vk.com/safinaskar Kazan, Russia
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
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. :)
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-bash@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
