Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interoperability with existing FORCE_COLOR uses #30

Open
epage opened this issue Jun 4, 2024 · 1 comment
Open

Interoperability with existing FORCE_COLOR uses #30

epage opened this issue Jun 4, 2024 · 1 comment

Comments

@epage
Copy link

epage commented Jun 4, 2024

Just found out about this project (see astral-sh/uv#3955) which seems to be trying to document and standardize FORCE_COLORs behavior.

It seems like it would be helpful to specify the behavior to be compatible with major users.

Behaviors I've seen through a quick survey

@shadowspawn
Copy link

shadowspawn commented Nov 22, 2024

For reference, two major implementations I have looked at in node ecosystem and linked from force-color.org do not follow the description on force-color.org. The primary use in both cases is levels 0-3 with some other values explicitly supported. I think in practice other environment variables like CLICOLOR_FORCE and NO_COLOR have simpler patterns of usage than FORCE_COLOR for forcing color on/off.

The node implementation mentions being inspired by the supports_color package. Levels 1-3 correspond to 16 colours, 256 colours, and 16M colours.

FORCE_COLOR result
supports_color
empty on, level 1
'0' off
'1', '2', '3' on
'true' on, level 1
'false' off
other non-number ignored
node
empty on, level 1
'1', '2', '3' on
'true' on, level 1
other off

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants