5 ms·

A lot of these tools assume that you’re using a dark theme. If you’re using a white-ish background (even worse somewhat beige, like I do), things like text high

A lot of these tools assume that you’re using a dark theme. If you’re using a white-ish background (even worse somewhat beige, like I do), things like text highlighted in yellow become invisible. Also, some of these tools don’t detect when they are run in a non interactive shell and will continue to write color codes when piped. A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection

messe 5y ago
> A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.
- mrighele 5y ago
  For me no, but I think it depends a lot on the experience of the developer and the language it is using. And environment variable is more common knowledge, it's cross platform and supported in any decent language. I bet that many don't even know that something like isatty(3) exists.
  - zinekeller 5y ago
    > I bet that many don't even know that something like isatty(3) exists. Also shell scripts can't directly use that.
    - messe 5y ago
      Sure, and that's why POSIX provides `test -t`.
goodpoint 5y ago
Something like COLOR=(light|dark|none) would be much better.
- donatj 5y ago
  Please don’t make me implement multiple color schemes for my shell scripts.
  - goodpoint 5y ago
    shell scripts? No, it's for CLI applications that provide colored output. Some assume dark background and some assume light background, making a mess. A simple 3-state variable solves the problem easily.
user-the-name 5y ago
That sounds like a problem with the palette your terminal is using, and not with the fact that programs use colour.
necovek 5y ago
ANSI terminals only offer 8 colours (extended to 16 with some tricks) based on grey-on-black screens of old. They, by default, have a certain set of features (like which colour contrasts which colour). Basically, it's a very limited palette, and it's up to the theme to maintain all the properties and features that hold between original colours. While developers can make use of more than 8/16 colours today, I find that extremely rare, and if a colour display for an app does not work on your theme, it's either an app problem in that it wouldn't work well in any terminal, or a theme problem. If it's an app issue, what makes you believe an author would rather implement NO_COLOR instead of fixing colour choices they made?
rolandog 5y ago
Agreed. I'm guilty of scratching my own itch and inferring dark themes and interactive sessions, but it's nice to build things in a manner that may allow for a better integration with something else.
Udo 5y ago
Implementing a flag like COLOR=light|dark|none puts the onus on application developers to interpret the user's configuration. I think it would be more reasonable to define a standard set of environment variables based on semantics that can then be used explicitly by scripts and programs. Like CL_WARN=(code for red) CL_HILIGHT=(code for yellow) CL_OPTIONAL=(code for gray). This would make it very easy on script developers, who would only need to use these variables instead of their hard-coded ones.
mminer237 5y ago
I feel like that's a problem with the terminal's theme. If you use a light theme, you should change yellow's color to be readable.

messe 5y ago

> A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.

mrighele 5y ago
For me no, but I think it depends a lot on the experience of the developer and the language it is using. And environment variable is more common knowledge, it's cross platform and supported in any decent language. I bet that many don't even know that something like isatty(3) exists.
- zinekeller 5y ago
  > I bet that many don't even know that something like isatty(3) exists. Also shell scripts can't directly use that.
  - messe 5y ago
    Sure, and that's why POSIX provides `test -t`.

goodpoint 5y ago

Something like COLOR=(light|dark|none) would be much better.

donatj 5y ago
Please don’t make me implement multiple color schemes for my shell scripts.
- goodpoint 5y ago
  shell scripts? No, it's for CLI applications that provide colored output. Some assume dark background and some assume light background, making a mess. A simple 3-state variable solves the problem easily.

user-the-name 5y ago

That sounds like a problem with the palette your terminal is using, and not with the fact that programs use colour.

necovek 5y ago

ANSI terminals only offer 8 colours (extended to 16 with some tricks) based on grey-on-black screens of old. They, by default, have a certain set of features (like which colour contrasts which colour). Basically, it's a very limited palette, and it's up to the theme to maintain all the properties and features that hold between original colours. While developers can make use of more than 8/16 colours today, I find that extremely rare, and if a colour display for an app does not work on your theme, it's either an app problem in that it wouldn't work well in any terminal, or a theme problem. If it's an app issue, what makes you believe an author would rather implement NO_COLOR instead of fixing colour choices they made?

rolandog 5y ago

Agreed. I'm guilty of scratching my own itch and inferring dark themes and interactive sessions, but it's nice to build things in a manner that may allow for a better integration with something else.

Udo 5y ago

Implementing a flag like COLOR=light|dark|none puts the onus on application developers to interpret the user's configuration. I think it would be more reasonable to define a standard set of environment variables based on semantics that can then be used explicitly by scripts and programs. Like CL_WARN=(code for red) CL_HILIGHT=(code for yellow) CL_OPTIONAL=(code for gray). This would make it very easy on script developers, who would only need to use these variables instead of their hard-coded ones.

mminer237 5y ago

I feel like that's a problem with the terminal's theme. If you use a light theme, you should change yellow's color to be readable.