1. That then breaks any applications that look for either `xterm` or `256-colors` in the TERM string. Unfortunately these days $TERM behaves more like a User-Agent string in HTTP-land so most terminal emulators are forced to pretend to be `xterm` even when they're not.
2. `export` is a Bourne Shell-ism. Powershell's syntax looks a little more like:
> Terminfo is mostly a file based database collection. You don't need to link to the C library, you just must be able to read the terminal infos.
mostly is doing a lot of heavy lifting there.
Also reading those databases without C is non-trivial as well. For example try manually parsing the output of /usr/share/terminfo/74/tmux-256color on macOS.
It's also worth noting here that there's two different database formats: terminfo and termcap. And different locations each platform (and users!) might configure those databases to reside.
Also tools like `tput` do more than just look up $TERM against terminfo. There are actually a few different places where terminal capabilities are hidden. Including ANSI escape codes, which was originally used in the hardware terminal days before $TERM existed and are still expected to be supported by modern terminal emulators.
Let's not forget that you also need to check if you're reading from, or writing to, a TTY. It might actually be a pipe, or even just a regular file. And while there is a standard C API for checking if a file descriptor is a TTY, `isatty()`, that itself is just a hack because there's no ABI in TTYs to return true/false if they are a TTY. So instead isatty() has to send ioctl calls to alter the state of the TTY, but a state that's only supported by TTYs (ie incompatible with pipes and regular files). It's a hack that's worked well for decades, but it's yet another class of edge cases that people take for granted.
> The question is not about support but about how to get them to be display. Which escape sequences produces colors 8-15? The answer is different from terminal to terminal and that's the problem.
What differs is the shade of colours that are produced with those escape codes. And that's exactly why I advocate that developers should stick to 3/4-bit code.
The point I'm making is that those colours are defined by the terminal and configurable by the user. Which means individuals can set a colour profile that is readable for them. This is why CLI and TUI developers should default to, and respect, those preferences.
Take a read through my comment history. I'm an author of a multitude of advanced CLI and TUI applications as well as terminal emulator and thus I've discussed these topics at great lengths with other people.
A few problems with that:
1. That then breaks any applications that look for either `xterm` or `256-colors` in the TERM string. Unfortunately these days $TERM behaves more like a User-Agent string in HTTP-land so most terminal emulators are forced to pretend to be `xterm` even when they're not.
2. `export` is a Bourne Shell-ism. Powershell's syntax looks a little more like:
https://learn.microsoft.com/en-us/powershell/module/microsof...> Windows is POSIX. Windows NT always had a POSIX layer.
Windows is not POSIX. Windows has POSIX compatibilities in some places but POSIX defines a plethora of different things beyond just C-APIs.
For example: Windows doesn't have a lot of the command line utilities defined by POSIX: https://en.wikipedia.org/wiki/List_of_POSIX_commands
> Terminfo is mostly a file based database collection. You don't need to link to the C library, you just must be able to read the terminal infos.
mostly is doing a lot of heavy lifting there.
Also reading those databases without C is non-trivial as well. For example try manually parsing the output of /usr/share/terminfo/74/tmux-256color on macOS.
It's also worth noting here that there's two different database formats: terminfo and termcap. And different locations each platform (and users!) might configure those databases to reside.
Also tools like `tput` do more than just look up $TERM against terminfo. There are actually a few different places where terminal capabilities are hidden. Including ANSI escape codes, which was originally used in the hardware terminal days before $TERM existed and are still expected to be supported by modern terminal emulators.
Let's not forget that you also need to check if you're reading from, or writing to, a TTY. It might actually be a pipe, or even just a regular file. And while there is a standard C API for checking if a file descriptor is a TTY, `isatty()`, that itself is just a hack because there's no ABI in TTYs to return true/false if they are a TTY. So instead isatty() has to send ioctl calls to alter the state of the TTY, but a state that's only supported by TTYs (ie incompatible with pipes and regular files). It's a hack that's worked well for decades, but it's yet another class of edge cases that people take for granted.
> The question is not about support but about how to get them to be display. Which escape sequences produces colors 8-15? The answer is different from terminal to terminal and that's the problem.
The escape codes don't differ. There is one standard set of escape sequences for 4-bit (8->15). https://en.wikipedia.org/wiki/ANSI_escape_code#3-bit_and_4-b...
What differs is the shade of colours that are produced with those escape codes. And that's exactly why I advocate that developers should stick to 3/4-bit code.
The point I'm making is that those colours are defined by the terminal and configurable by the user. Which means individuals can set a colour profile that is readable for them. This is why CLI and TUI developers should default to, and respect, those preferences.
Take a read through my comment history. I'm an author of a multitude of advanced CLI and TUI applications as well as terminal emulator and thus I've discussed these topics at great lengths with other people.