Created attachment 331082 [details] screen shot Look at the screen shot - it works well, if I started a new terminal or when I run "clear" before. But if eix has to scroll during it output then the background colour (at least here in the KOnsole in KDE 4.9.3) is wrongly reseted, meaning that after the PS1 prompt the back ground colour is wrong.
this is a dup of the bug #438076
This is not related with eix: printf '\033[43mCOLOR\n\e[0mNOCOLOR\n' is interpreted falsely in konsole-4.9.3 when scrolling is needed.
(In reply to comment #2) > This is not related with eix: > > printf '\033[43mCOLOR\n\e[0mNOCOLOR\n' > > is interpreted falsely in konsole-4.9.3 when scrolling is needed. ? - xterm fails in the same way here
(In reply to comment #3) > ? - xterm fails in the same way here You are right: I had tmux running when I tested which does not have this bug. The problem is that if the background color has temporarily changed and a new line is scrolled in (for whatever reason: a newline or a line wider than the terminal width; both only if you are at the last line of the terminal) then the background color for the *whole* new line becomes the termporary background color. I still consider this behavior a bug: the same escape sequences cause whole line-tails to have different colors, depending on the width of the terminal and depending on whether scrolling is necessary. However, since several terminals suffer from the same bug, this seems to be a bug "by tradition" - apparently, eix is the first application stressing the background color so much that this bug becomes evident. I am not sure what to do. Certainly, I will add workarounds to eix by resetting background colors before sending linefeeds, but this still breaks if lines longer than the terminal width are output: This is only a workaround and not a true bugfix. The following example demonstrates the problem: Let the following run in the _last line_ of a 80-character wide konsole: printf '\033[43m%81s\033[44m \033[0m\n' Compare this when you replace 81 by 80 and by 70, respectively: Only the latter corresponds to the (correct) result which you see if you run the command in the first line of an xterm or console.
How about to report this to upstream or is this a gentoo exclusive problem?
It's simple to state, subtle in the way it works. Aside from ensuring that terminals implement bce consistently (and that applications have the same understanding), I don't see a way to address your concerns.
(In reply to Thomas Dickey from comment #6) > It's simple to state, subtle in the way it works. > Aside from ensuring that terminals implement bce > consistently (and that applications have the same > understanding), I don't see a way to address your > concerns. I dont see a packaging issue here. Please report upstream we cant much do about it.
Upstream problem, please report there.
