Jde*_*eBP 16
是否有一些环境变量?
是的。它是TERM
环境变量。这是因为有几件事被用作决策过程的一部分。
在这里很难概括,因为并非所有程序都同意一个决策流程图。事实上grep
,在 M. Kitt 的回答中提到的GNU是一个很好的例子,它使用了一个有点不寻常的决策过程,结果出乎意料。因此,笼统地说:
isatty()
。TERM
环境变量必须存在和它的价值必须与数据库记录相匹配。TERMCAP
环境变量指定 termcap 数据库的位置。所以在某些实现上有第二个环境变量。max_colors
terminfo 中有一个字段。它不是为实际上没有颜色功能的终端类型设置的。事实上,有一个 terminfo 约定,对于每个可着色的终端类型,都有另一条带有-m
或-mono
附加到名称的记录,说明没有颜色功能。set_a_foreground
和set_a_background
字段。它比仅仅检查要复杂一些isatty()
。它因以下几件事而变得更加复杂:
isatty()
检查,以便程序始终或从不假定它具有(可着色的)终端作为其输出。举些例子:
ls
有--color
命令行选项。ls
着眼于CLICOLOR
(它的缺失意味着从不)和CLICOLOR_FORCE
(它的存在意味着总是)环境变量,并且还运行-G
命令行选项。TERM
.如前所述,GNUgrep
实际上展示了其中一些额外的复杂性。它不咨询 termcap/terminfo,硬连线要发出的控制序列,并将响应硬连线到TERM
环境变量。
它的Linux/Unix 端口具有以下代码,仅当TERM
环境变量存在且其值与硬连线名称不匹配时才启用着色dumb
:
整数 should_colorize(无效) { char const *t = getenv ("TERM"); 返回 t && strcmp (t, "dumb") != 0; }
因此,即使您TERM
是xterm-mono
,GNUgrep
也会决定发出颜色,即使其他程序vim
不会。
它的Win32 端口具有此代码,它在TERM
环境变量不存在或存在且其值与硬连线名称不匹配时启用着色dumb
:
整数 should_colorize(无效) { char const *t = getenv ("TERM"); 返回 !(t && strcmp (t, "dumb") == 0); }
grep
的颜色问题GNUgrep
的着色实际上是臭名昭著的。因为它实际上并没有正确地构建终端输出,而只是在其输出的不同点指责一些硬连线控制序列,徒劳地希望这足够好,它实际上在某些情况下显示不正确的输出。
在这些情况下,它必须为终端右侧边缘的东西着色。正确执行终端输出的程序必须考虑自动右边距。 除了终端可能没有它们的轻微可能性(即auto_right_margin
terminfo 中的字段)之外,具有自动右边距的终端的行为通常遵循挂起换行的 DEC VT 先例。GNUgrep
没有考虑到这一点,天真地期望立即换行,它的彩色输出出错了。
彩色输出不是一件简单的事情。
grep --color
没有显示正确的输出”。xterm 常见问题解答。隐形岛。