Bold LSCOLORS not working

Hi,

Trying to introduce some color, while customising some of it. I have the following in .cshrc:

Code:
setenv  CLICOLOR
setenv  LSCOLORS 'Ex'
set listflags = A
set color = ls-F

This adds some color, but LSCOLORS doesn't seem to work as expected. I am seeing some strange behaviour, and I'm not sure what's going on or whether I've missed something.

I can print the bold color explicitly, and it is also the color I use in the prompt, but for LSCOLORS the bold "flag" is effectively ignored, using the normal blue. I am able to use entirely different colors, so the variable works to some extent. ls-F also seems to honor LS_COLORS (with the underline), while ls does not.

This is on FreeBSD 13.3, tcsh 6.22.04, xterm-256color.

1734099214241.png
 
Are you sure bold actually works at the level of your terminal?

In terminal emulators, there are two ways to display bold: One is to use a bolder font (more pixels of foreground), the other is to make the color brighter. I know the Linux console uses the brighter color technique, while my favorite terminal emulator on a windowing system (iTerm on the Mac) uses the bolder font.

How to check this? In a shell, use "echo foo esc [ 1 m bar esc [ 0 m" (with all the spaces between the arguments removed, and esc typed using the keyboard prefix for literal character, which is control V. You should see the difference between foo and bar. If you want to try different colors, add "esc [ 3x m" before the bar, where x is 0 to 7. Play a little bit with the colors this way to get a feel for what is even possible.
 
<OT>
I also found that using '\e[01;37m' the color is bright white + bold, while '\e[00;97m' the color is bright white (no bold). I found this while trying some packages (javascript and python) that outputs ANSI color text, they output the bold attribute separated by the dark/bright attribute. I tryied all CSR codes (other than 30-37, 40/47) for colors and found 90-97 for bright foreground colors (like 30-37) with no bold attribute. I do not know if this is standard or not and if it works on any terminal, I use xtrerm-256color and works in virtual and pseudo terminals.
<OT>
 
<Also OT>
Be careful with using the colors white and black (37 and 30 for foreground), because their meaning depends on the terminal background: If you have the terminal background set to the common black, and use "esc [ 30 m" to set the foreground color to black, the text becomes invisible; on a white background, the same escape sequence makes it visible, while "esc [ 37 m" makes it invisible. Also be careful when using the color yellow = 33, in particular if you want to associate it with "warning", since on many terminals it actually looks more like a brown. To really do this right would require using the OSC sequences to ask the terminal emulator what the 24-bit RGB values for foreground and background are, and do a careful UI/UX design of the color scheme, and then use the most appropriate color escape sequences (which may require using the 24-bit versions).

Failing that, in my opinion, using the color escape sequences needs to be kept pretty simple: You can rely on default foreground and default background (inverse = "esc [ 7 m"), you can rely on red/green/blue/cyan/magenta, and everything else (including bold) is unreliable or a mistake waiting to happen.
 
Are you sure bold actually works at the level of your terminal?
From reading some other threads, I was not entirely sure whether bold and "bright" was two different things, but whatever the definition, it does work, as per the first command in my screenshot, as well as in LS_COLORS.

I would like to stick to BSD ls, but it's starting to sound like this is not a supported configuration? It is mentioned in my installed ls man page, though. I followed the colorizing guide, although bold LSCOLORS was not specifically shown working.
 
I don't know whether this is meaningful, but using script, I can see that entirely different color sequences are used for the listing. Here using setenv LSCOLORS ExCx.

Code:
Script started on Mon Dec 16 09:28:11 2024
^[]0;root@LP52:~^G^[[31;1mroot@LP52^[[0m:^[[34;1m~^[[0m # printf '\033[34mNORMAL\033[0m \033[34;1mBOLD\033[0m \033[38;5;4mBOLD\033[0m\n'^M
^[[34mNORMAL^[[0m ^[[34;1mBOLD^[[0m ^[[38;5;4mBOLD^[[0m
^[]0;root@LP52:~^G^[[31;1mroot@LP52^[[0m:^[[34;1m~^[[0m # ls -lI^M
total 10
drwxr-xr-x  5 root  wheel  20 Mar 29  2023 ^[[1m^[[38;5;4mbackup^[[39;49m^[[m
drwxr-xr-x  2 root  wheel   4 Apr 25  2019 ^[[1m^[[38;5;4mbin^[[39;49m^[[m
lrwxr-xr-x  1 root  wheel   4 Dec 16 09:27 ^[[1m^[[38;5;2mlink^[[39;49m^[[m -> link
-rw-r--r--  1 root  wheel  43 Dec 16 09:28 typescript
^[]0;root@LP52:~^G^[[31;1mroot@LP52^[[0m:^[[34;1m~^[[0m # ^D^H^Hexit

Script done on Mon Dec 16 09:28:24 2024

1734339076421.png


Edit: This seems to be an issue with Windows Terminal and/or xterm-256color. The colors are for some reason being converted to 256 color notation, where the bold flag is lost, while the same is not true for the colors in the prompt and the explicit printf. It seems to work correctly in the console, where it uses xterm. I also don't have the same issue in Debian and, of course, ls-F, as mentioned earlier. I don't know whoever does these things decides to convert only these color sequences.
 
Welcome to the world of ANSI escape sequences, which is also the world of frustration. I've spent quite a few hours tweaking how my programs use colors and Unicode characters in console mode, and made it work with the few terminal emulators I use. Having to also teach existing programs like ls to do it right would be a lot of extra work.

For fun, here is an example output of the CLI version of my home equipment monitoring program. Note bold, underline, colors (green and yellow here only, blue and red also exist, and dim black for unimportant stuff). This is probably already more than is sensible.

Screenshot 2024-12-16 at 1.35.11 PM.png
 
Back
Top