FreeBSD unexpected bold color behaviour

[etfz]

Hi,

I'm using the LSCOLORS environment variable in order to color ls output in FreeBSD. It supports using bold colors, but the result is not bolded. (brightened) Using the script utility, I can see that bold blue comes out like this:

^[[1m^[[38;5;4mbackup^[[39;49m^[[m

At the same time, I am able to print the color as expected elsewhere.

$ printf '\033[34mNORMAL\033[0m \033[34;1mBOLD\033[0m \033[38;5;4mBOLD\033[0m\n'
^[[34mNORMAL^[[0m ^[[34;1mBOLD^[[0m ^[[38;5;4mBOLD^[[0m

The same color works as expected in the console: (xterm)

^[[1m^[[34mbackup^[[39;49m^[[m

I don't have the same problem with ls on at least Debian machines, but I don't know how it works there, and I use default settings.

https://forums.freebsd.org/threads/bold-lscolors-not-working.96054/

First and foremost I'm wondering what causes this. I suspect it is related to my terminal being xterm-256color, which I assume is somehow set by Windows Terminal, but does Windows Terminal do anything special? I found a few open issues regarding bold color support, but I am not sure which ones are relevant here.

[DHowett]

You know what? I definitely misread this. Sorry!

Colors specified using the xterm 256-color graphic rendition attribute will not be automatically brightened. Brightening applies only to ANSI colors 0-7 specified via SGR 30-37, and that's a compatibility feature.

The setting I mentioned above won't change this behavior.

Stealing from a previous comment chain...

Thanks for the report! This was an intentional decision, based on how other terminal emulators work. I went and dug up some of our older discussions to give you more context. 😄
Here's the short version:

• xterm 331 chose to brighten 256-indexed colors 0-7
• xterm 348 silently reverted this behavior
• An issue was filed on libvte (engine powering gnome-terminal) documenting the above: gitlab.gnome.org/GNOME/vte/-/issues/149
• We have an issue discussing this: Should the bold/bright attribute apply to SGR 38/48 indexed colors? #5384

I'll tentatively close this one out as a /duplicate of #5384 😄

Stealing some notes from #11507 (comment)

[etfz]

Thanks! So, could you help me understand what's actually going on? This is what I've understood so far:

• When xterm-256color is in use, ls prints color using 256 color notation instead of 16 color notation. (despite LSCOLORS only seeming to support 16 colors?)

https://man.freebsd.org/cgi/man.cgi?query=ls&sektion=1&manpath=freebsd-release-ports#ENVIRONMENT

I thought I understood which color sequences belonged where, but now I'm not sure.

• \e[34m is the normal "16 color" blue.
• \e[1;34m is bold 16 color blue, commonly rendered as bright blue.

But then I found out about the 90s range, which is "high intensity". I'm not sure where that fits. (later addition?)

• \e[94m is "high intensity" blue. Rendered as bright blue.

256 color notation is slightly different, using a prefix of 38;5 in order to define foreground color, and defines bold differently. I don't know whether the style flags technically have anything to do with the color notations.

• \e[38;5;4m - normal blue.
• \e[1m\e[38;5;4m - normal blue with bold flag.
• \e[38;5;12m - bright blue.

So in xterm-256color, ls uses \e[1m\e[38;5;4m instead of \e[1;34m in order to print bold blue, which are both correct.

Am I correct in thinking Windows Terminal has not come into the picture yet?

The problem, then, is that while Windows Terminal sees \e[1;34m as bright blue, it only sees \e[38;5;4m as normal blue, and ignores the bold flag \e[1m? If so, this seems a little strange to me. I would at least expect some kind of option to use this flag for brightening, similar to what the existing option does. If we ignore technicalities such as backwards compatibility, is there a reason for the current behaviour? Or have I misunderstood something?