I fiddled with this for a couple of hours and couldn't find a solution...

Lets say I print this to a terminal (tested with bash and zsh in a genome-terminal in a VM running a fresh Linux Mint):

  • \033[41m enables a red background for the text that follows.
  • \033[0m resets the background to the default.
  • Assume that there are enough O's to generate an output which fills exactly one and a half lines in the terminal.

In a fresh terminal the output looks like this (like I expected):

|OOOOOOOOOOOOOO BAR               |
|==============                   |
|                                 |
  • Every char that is underlined with a = has a red background.
  • | Defines the border of the terminal.

So we see FOO... with a red background and BAR without a red background.

If I run the command again I get this:

|OOOOOOOOOOOOOO BAR               |
|==============    ===============|
|                                 |

After BAR the line continues to be red... and I have no clue why? Any idea?


iTerm2 on Mac OS X also does this when the colored text wraps past the available columns. One workaround may be to erase to the end-of-the-line after writing BAR via the CSI Ps K Erase in Line (EL) control sequence, e.g.

$ perl -e 'print "\e[41m".("a"x120)."\e[0mBAR\e[K"'
| improve this answer | |
  • This does seem to work nicely when I replace \e with \33. Such a relief! Thanks :) – Rotareti Jul 31 '17 at 19:19
  • Many terminals do this. It's the normal behaviour, when scrolling, of a terminal that implements background colour erase. The new line scrolled up at the bottom of the scrolling area is erased with the current background colour. – JdeBP Jul 31 '17 at 19:52
  • @JdeBP, In the GNU screen terminal emulator, you can issue the bce off command to turn off that behaviour. – Stéphane Chazelas Aug 3 '17 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.