6

I am encountering strange behaviour when trying to switch on and off background colors in terminal output:

#!/bin/sh printf "\e[48;5;203m" printf "AAA\n" printf "\e[0m" printf "BBB\n" printf "CCC\n"

I want AAA to be printed with red background, then switch off the background color, and print the next lines. However, this is how the output looks like:

enter image description here

UPDATE

OK, I tried from a new terminal, and there it works as expected. But I still have the old terminal window open, where I get the output as shown. What is happening there? Is there some "garbage" left in the terminal, that is causing this?

I did reset in the old terminal window, and the output is now correct.

Improve this question
5
  • 2
    It works as intended on my terminal (KDE Plasma, Konsole). Commented Sep 13, 2022 at 6:48
  • Same on xterm (work as intended) Commented Sep 13, 2022 at 6:52
  • thank you, please see my update Commented Sep 13, 2022 at 6:59
  • Why don't you just use one command? printf "\e[48;5;203mAAA\e[0m\nBBB\nCCC\n" works as expected and doesn't have the issues you mention. Commented Sep 13, 2022 at 14:49
  • 2
    @terdon - because instead if printf "AAA\n" there is actually output coming from a command. I used simplified code for demonstration. Commented Sep 13, 2022 at 17:47

2 Answers 2

Reset to default
19

When AAA\n is printed at the very bottom of the terminal, the terminal needs to scroll the text and make an empty line appear at the bottom. It displays the line using the current background color, which is red. Then BBB\n is printed over this background, using its own background color. The new background color affects only few characters in the current line (BBB), but it is relevant when the next empty line appears. In effect the next line (where CCC is going to appear) looks normal.

When AAA\n is printed not at the bottom, the terminal does not need to add a line, empty space is already there. It so happens the empty space is black.

To reproduce, run your code several times until you get to the bottom of the terminal and "beyond".

The following two commands, when repeated (each one in its own terminal), give output that looks identical, until the bottom is reached:

  1. printf "\e[48;5;203mAAA\n\e[0m" 
  2. printf "\e[48;5;203mAAA\e[0m\n"

In the second case the background gets reset before \n.

My testbed: Konsole 21.12.3, TERM=xterm-256color.

Improve this answer
2
  • 1
    Exactly! when I reach the bottom of the terminal, it starts to look broken like on my screenshot. So is this a bug in the terminal emulator? Commented Sep 13, 2022 at 8:45
  • 5
    @400 I wouldn't call it a bug. The current background color affects more things: e.g. clear after your printf "AAA\n" makes the entire area turn red. And if I had to call one of the two behaviors "broken", I would say the not-at-the-bottom one is "broken". Apparently you would disagree. I could fix what I'd find "broken" with tput el just after your printf "AAA\n". Truly I find neither behavior broken; I accept the fact \n in some circumstances results in a line of different color. Terminals are already a zoo and we need TERM, tput and e.g. ncurses to work reliably with them. Commented Sep 13, 2022 at 16:37
-1

As @Kamil Maciorowski answered, you should revert the background color before printing the newline.

However, that might still give you unexpected background color, depending on:

  • whether there's an implicit linewrap (the text you print is wider than the terminal),
  • whether you cause the terminal to scroll or not,
  • the concrete choice of terminal emulator, further boiling down to:
    • whether it implements "background color erase" (bce) or not,
    • whether it (intentionally or accidentally) deviates from the standard (xterm) bce implementation.

You might be interested in https://bugzilla.gnome.org/show_bug.cgi?id=754596 for juicy details explaining an inevitable problem with xterm's bce handling, and how VTE (GNOME Terminal etc.) intentionally changed the behavior to fix that problem in a way that doesn't cause known regressions in existing apps.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.