On Wed, 25 Oct 2023 at 11:51, Greg Wooledge <g...@wooledge.org> wrote: > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote:
> > Description: > > The initial bash background is hardcoded to some default (e.g. black) and > > cannot be colorized by printing "transparent" tabs/newlines with > > ANSI-ESC-codes. > > Only after a vertical scrollbar appears, the whitespace beyond the window > > hight will get the proper background color. > > Terminals have colors (foreground and background). Bash does not. Bash > is just a command shell. > > > Repeat-By: > > run the following command line: > > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' > > Play with the parameter to seq, to keep the line within the first screen or > > move it offscreen. > > > > Reproduced in: > > - in Konsole on Kubuntu 23.04 > > - in the git bash for windows mintty 3.6.1 > > - in WSL cmd window on Windows 11 > > I ran this command in xterm (version 379) and rxvt-unicode (9.30) on > Debian, but I'm not sure what I'm supposed to be seeing. The bug being reported is that the '\t' characters have a black background if the 'seq' argument is low enough that its lines 1 and 2 remain visible when run. But if the 'seq' argument is changed to be bigger, so that (at least) lines 1 and 2 both scroll off the top of the terminal window so that they are not visible, then the '\t' characters then get the expected blue background. I see this in Debian 11, both in 'lxterminal' under LXDE, and in the virtual consoles, [david@kablamm ~]$ echo $BASH_VERSION 5.1.4(1)-release [david@kablamm ~]$ cat /etc/debian_version 11.8
