ShouldColorize::from_env() does not look the TERM environment variable

[fhars]

ShouldColorize::from_env() completly ignores wether it runs in an environment that is capable of displaying colors or not and always generates color control codes.

Steps to reproduce:

1. Write a test program that uses colored.
2. Start the program with TERM=dumb ./my-test-program

Expected behavior:

3. The output in uncolored.

Observed behavior:

3. The output is colored.

[fhars]

This patch fixes it for me, no idea what it does on windows: 0001-query-terminfo-color-capabilities.txt

(And how stupid is it that github does not allow to attach patches to issues?)

[Horgix]

(And how stupid is it that github does not allow to attach patches to issues?)

To be fair, if you embed it inside a code block with the patch syntax it correctly displays it:

From dfc8e146672fcae0a1d0a918dfb831d92392ebbb Mon Sep 17 00:00:00 2001
From: Florian Hars <[email protected]>
Date: Mon, 4 Apr 2022 16:43:51 +0000
Subject: [PATCH] query terminfo color capabilities

---
 Cargo.toml     |  3 ++-
 src/control.rs | 11 +++++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Cargo.toml b/Cargo.toml
index 886b29e..6e8d81f 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,7 +1,7 @@
 [package]
 name = "colored"
 description = "The most simple way to add colors in your terminal"
-version = "2.0.0"
+version = "2.0.1"
 authors = ["Thomas Wickham <[email protected]>"]
 license = "MPL-2.0"
 homepage = "https://github.com/mackwic/colored"
@@ -16,6 +16,7 @@ no-color = []
 [dependencies]
 atty = "0.2"
 lazy_static = "1"
+terminfo = "0.7"
 
 [target.'cfg(windows)'.dependencies.winapi]
 version = "0.3"
diff --git a/src/control.rs b/src/control.rs
index 7ad6e62..0aae563 100644
--- a/src/control.rs
+++ b/src/control.rs
@@ -104,8 +104,15 @@ impl ShouldColorize {
     /// followed by `CLICOLOR` combined with tty check.
     pub fn from_env() -> Self {
         ShouldColorize {
-            clicolor: ShouldColorize::normalize_env(env::var("CLICOLOR")).unwrap_or_else(|| true)
-                && atty::is(atty::Stream::Stdout),
+            clicolor: (ShouldColorize::normalize_env(env::var("CLICOLOR")).unwrap_or(true))
+                && atty::is(atty::Stream::Stdout)
+                && (if let Ok(db) = terminfo::Database::from_env() {
+                    db.get::<terminfo::capability::MaxColors>()
+                        .map(|mc| 2 < mc.into())
+                        .unwrap_or(false)
+                } else {
+                    true
+                }),
             clicolor_force: ShouldColorize::resolve_clicolor_force(
                 env::var("NO_COLOR"),
                 env::var("CLICOLOR_FORCE"),
-- 
2.25.1

As for the purpose itself, I'm not the best to answer it - so far I always made sure to define the "standard" NO_COLOR environment variable in restrained-output environments when using this crate

[fhars]

Emacs compilation mode doesn't, it allocates a pty and sets TERM=dumb, which has been the standard way to do this since 1978.

[mackwic]

Hi @fhars thank you for the feature request.

It seems that you're not familiar with Github, keep in mind that everyone here is a benevolent contributor, please be nice and respectful of the others.

[kalvdans]

I've made a merge request from @fhars patch where we can discuss the code or extra requirements further, see #129