Terminal Style Support Not Properly Detected

[pucheGit]

Short Version:

• minikube uses $TERM to determine if the terminal supports color, this is insufficient. $COLORTERM should also be checked.
• pkg/minikube/out/out.go should be changed on/around line 163 to correct this issue.

The exact command to reproduce the issue:

echo $TERM
minikube start
#CTRL+C
TERM=xterm-256color
minikube start

The full output of the command that failed:

$> echo $TERM
xterm-termite
$> minikube start
* minikube v1.4.0 on Debian parrot
* Downloading VM boot image ...
^C
$> TERM=xterm-256color
$> minikube start
😄  minikube v1.4.0 on Debian parrot
💿  Downloading VM boot image ...
^C
$> env | grep COLOR
COLORTERM=truecolor

The operating system version:

minikube version: v1.4.0
commit: 7969c25a98a018b94ea87d949350f3271e9d64b6

Suggested Change:

/pkg/minikube/out/out.go Line 163

     term := os.Getenv("TERM")
     colorTerm := os.Getenv("COLORTERM")
     // Example: term-256color
     if !strings.Contains(term, "color") && !strings.Contains(colorTerm, "truecolor") && !strings.Contains(colorTerm, "24bit") && !strings.Contains(colorTerm, "yes") {
         glog.Infof("TERM=%s,COLORTERM=%s, which probably does not support color", term,colorTerm)
         return false
     }

[tstromberg]

Do you mind providing an example of an environment that the current logic gets incorrect? It would help to understand the PR better.

[pucheGit]

I use the termite terminal on a Debian 10 system. This terminal sets TERM=xterm-termite. Since, this does not contain the substring "color" the logic fails to recognize that termite does in fact support colors/styles. As a result, minikube chooses not to display the unicode symbols by default. The terminal does, however support both unicode and truecolor. The terminal sets the environment with COLORTERM=truecolor which is one of several standard values that signifies support for colors. What I proposed is a minor change to look for the common values that COLORTERM gets set to in order to signify this support.

Currently, I believe any environment in which the terminfo name, represented by environment variable TERM does not contain the string "color", but the terminal has color/unicode support would suffer from this issue.

A better solution may be to detect unicode support specifically, but I am unaware of a way to do this, and instead chose to match the current approach, but with a slightly increased fidelity.

If you have any other specific details that would help your understanding please let me know. I have also included my full environment, which suffers from this problem for completeness.

$> env
SHELL=/bin/bash
WINDOWID=25165831
COLORTERM=truecolor
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
SSH_AUTH_SOCK=/tmp/ssh-4hvwVbxHS88x/agent.2621
DESKTOP_SESSION=i3
SSH_AGENT_PID=2662
XDG_SEAT=seat0
PWD=/home/localadmin
LOGNAME=localadmin
XDG_SESSION_DESKTOP=i3
XDG_SESSION_TYPE=x11
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
XAUTHORITY=/home/localadmin/.Xauthority
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/localadmin
GDM_LANG=en_US.utf8
HOME=/home/localadmin
LANG=en_US.UTF-8
XDG_CURRENT_DESKTOP=i3
VTE_VERSION=5002
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
TERM=xterm-termite
USER=localadmin
DISPLAY=:0
SHLVL=1
XDG_VTNR=7
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/localadmin/.local/bin
GDMSESSION=i3
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
_=/usr/bin/env