Version: 1.1.3 (using KDE KDE 3.0.5) Installed from: Mandrake RPMs I have font = 'large', and when konsole is opened it appears at 62x20. I usually maximise it (it gets to 86x32) and eventually, after running some programs that display a lot of output (like mplayer or wget), I see the problem: I start to write, but when I reach column 62, the cursor jumps to the start of the line (the same line), overwriting what I wrote. It should continue until it arrives to column 86 (the last one) and then jump to the next line and first column. However, I can press Enter and the command will be executed normally. Pressing left/right keys and inserting or deleting some text causes total chaos. See the attached screenshot, where I typed "1234567980" five times.
Created attachment 808 [details] screenshot
I think this is a blocking bug; I have seen it with every version I tested. Can someone please investigate it further?
*** Bug 55330 has been marked as a duplicate of this bug. ***
> Can someone please investigate it further? Why not you? "sometimes" and "eventually" are not good descriptions how to reproduce this bug. Looking at these two reports it may be even Mandrake-specific (shell, libreadline, ...). Does this bug still occurs with Mandrake Linux 9.1?
binner: you're right, this can be Mandrake specific, as I have only seen it on Mandrake PCs (also 9.1). Thanks for the idea, I'm going to investigate it further. BTW, I have seen similar bugs that happen only by resizing the window (lost chars, broken lines, etc.)
Subject: Re: cursor jumps to the first column before reaching end of line Le Lundi 07 Avril 2003 08:22 PM, vous avez
I can reproduce it here using ArkLinux alpha7. To reproduce this bug do following: (1) Open konsole, (2) start a "full screen" app like top, then (3) maximized the konsole window. Now (4) quit top and (5) keep writing text, it will break at the right border of the windowed size of konsole and overwrite itself at the beginning of the same row. Now when you restore the previous window size the rows are shown correctly again. This behavior is independent of chosen initial window size and font size.
Thank you very much, Datschge! That reproduces the bug also on my Mandrake9.1 with icewm. However, it does not only affect konsole... aterm, xterm, Eterm, etc. do the same.
Happening with every terminal emulator? Good indication that it isn't a Konsole bug.
Subject: Re: cursor jumps to the first column before reaching end of line Le Mardi 08 Avril 2003 10:36 AM, vous avez
I can confirm that xterm shows the same behavior like konsole using the procedure I mentioned above, so resolving this bug as invalid since it's not related to konsole per se seems valid to me.
Ok, no problem. But now that we have identified the bug, where should we file it? It doesn't happen only in Mandrake but in ARK Linux (and probably others). They have one thing in common: they both run KDE (I tested this on a Debian with no KDE and worked ok).
Believe or not, they have much more in common (e.g. ncurses). Report the bug to your distributor, he should be able to fix it or identify and report it to the correct upstream source.
Ok, I filed this one: http://qa.mandrakesoft.com/show_bug.cgi?id=3747 Thanks, Binner, Datschge and Gerard.
This isn't a bug. =) See this howto for more info on how to correctly create color prompts with bash. As was mentioned, you have to use \[ and \] around control characters so that bash can count characters correctly. http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/ Especially see: http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html Which specially talks about this issue.
*** Bug 77817 has been marked as a duplicate of this bug. ***
*** Bug 68533 has been marked as a duplicate of this bug. ***
I've got no more this problem. But I don't know why...
I still do have this bug on KDE 3.3.1 running Slackware 10.0. You can simple reproduce this bug, by maximizing the konsole window and entering a lot of text into the konsole by hand (copy & paste will not show this bug!). For example just enter this: ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc .... (and a lot more c characters) It will end somewhere at the right side and start all over again at the beginning overwriting your bash prompt and user name. This means, it will NOT jump into the next row. In normal operation this can happen when working within large directory names entering long commands. For example when you are in /usr/local/share/bla/images/ and enter a long command like this one, it can happen: user@home:/usr/local/share/bla/images# cp /usr/local/share/bla/images/blablub.x /home/user/images/nature/xyc/12345/ This bug is existing since the beginning of KDE 2.0 and probably earlier. xterm and gnome-terminal do NOT show this bug, they work correctly. So i don't think it is a distribution or other library problem. It is definatly kde konsole specific.
Created attachment 9843 [details] Another screenshot showing Bug 53418 with some comments about the bug. The KDE Version is KDE 3.3.1 running on Slackware 10.
I just tested on KDE 3.4 and HEAD using steps in comment #7. The text layout works fine here... About comment #15: %echo $PS1 \[\033[0;32m\](\[\033[1;34m\]\u\[\033[1;32m\]@\[\033[1;34m\]\h\[\033[0;32m\])-(\[\033[0;36m\]$(date +%H:%M)\[\033[0;32m\])-(\[\033[0;36m\]\w\[\033[0;32m\])\[\033[0;36m\]>\[\033[0;37m\] \[\e]30;\w\a\] comment #19: again I can't reproduce uses your steps. Read the bug report on commet #14 for more info....
Then see at my screenshots as prove. It still does happen. The only problem is, it is not allways reproducable. Sometimes it works, sometimes not.