BUG: Colorize background of whitespace
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release 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. 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
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 11:09 AM Holger Klene wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto > -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security > -Wall > uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri > Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > 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. > > 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 guess this is the way terminal emulator works, and I guess as well they are doing what real terminals use to do, though I have no such term at hand to prove :-) Worth to consider $ clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' | expand
Re: BUG: Colorize background of whitespace
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. In my case, the terminals are 80x24, and xterm has a default black background, while rxvt has a default white background. In both cases, the expected rows of numbers are printed by seq, and then there's a blank line, and then there's a line of dark blue background which extends all the way across the terminal, containing "some colored" and "text with" and "tabs" in a greenish foreground color. Hitting Enter to scroll the text upward doesn't do anything surprising, and neither does scrolling the terminal with Shift-PageUp or with the mouse. What are *you* seeing which surprises you? In any case, this has nothing to do with bash. It's strictly a terminal issue, whatever the issue may be.
Re: BUG: Colorize background of whitespace
On Wed, 25 Oct 2023 at 11:51, Greg Wooledge 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
Re: BUG: Colorize background of whitespace
On 10/25/23 10:48 AM, David wrote: 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. Bash and readline don't do anything with terminal foreground colors and background colors except under certain circumstances like bracketed-paste. If you're pasting the above command into the terminal, that pasted text will be colored according to active-region-start-color and active-region-end-color (bash-5.2) or terminal standout mode (bash-5.1). Otherwise, readline redisplay just outputs terminal sequences to move the cursor and the characters in the line. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 02:48:20PM +, David wrote: > On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > > 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. > 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. Ahh. That wasn't clear to me. Thanks. In an 80x24 rxvt-unicode or xterm terminal, "seq 22" shows the reported problem, and "seq 23" does not.
