gnome-terminal用于显示具有某种颜色和粗体属性的字符，颜色比具有相同颜色但没有粗体属性的字符更亮，总共有 16 种可能的颜色。首选项页面仍有 16 种颜色可供选择，但似乎总是使用顶行，即使字符加粗也是如此。我似乎从未看到过使用底行颜色。
（这是玩 Nethack 时的一个问题，因为我习惯于看到 16 种不同颜色的怪物和物体。）
有没有办法让所有 16 种颜色恢复到以前的样子？
答案1
简短版本：请尝试一下TERM=xterm nethack，它很可能会奏效。
长版本：
请尝试并检查我的答案中的脚本输出在终端中打印 256 色测试图案。
您谈论的属性 ( \e[1m) 存在一个遗留问题，即它到底是意味着粗体、明亮还是两者兼而有之。随着几乎所有终端仿真器都出现了扩展的 256 色调色板，随后一些终端仿真器（包括 gnome-terminal）也出现了真彩色支持，人们的倾向转向这个属性意味着粗体。显然，它并不是要篡改直接 RGB 颜色，而且它对 256 色调色板也会造成问题（这些索引之间是否存在映射，或者它会导致调色板之外的颜色？）。
有多种方法可以访问调色板的前 16 个条目。带有数字 30–37（前景）和 40–47（背景）的传统转义序列代表前 8 个。如果将前景与 1（粗体/亮色）模式结合使用，出于传统兼容性原因，仍会启用其亮色对应项（例如，nethack看起来仍然和以前一样……叹气）。
代码 90–97（fg）和 100–107（bg）代表接下来的 8 个调色板条目，无论如何它们都是明亮的。
但是，新的 256 色调色板转义序列（fg 为 38;5;0 – 38;5;255，bg 为 48;5;0 – 48;5;255）的行为有所不同（遵循 xterm 的行为）：此处 1（粗体/亮体）属性仅启用粗体，不会改变颜色。
因此，在您的情况下，区别可能是您的应用程序过去发出老式的转义序列，但现在发出新的（256 色调色板）转义序列，它们引用同一调色板的颜色，唯一的区别是模式 1 的工作方式不同：在这里仅表示粗体，而不是粗体和亮体。
反过来（在推理链中倒推）这可能是由于 TERM 环境变量默认为 xterm-256color，而不是之前的 xterm。尝试恢复此变量，看看它对您的应用程序有何影响。
有些事情如果不调查的话我就无法理解（而且由于没有时间和兴趣也不会调查）：nethack 似乎在使用 ncurses。ncurses 不允许应用程序决定使用哪种转义序列，它只提供对 256 种颜色的访问，而对前 16 种颜色使用哪种转义序列是 ncurses 的私事。事实上，从和的输出可以看出，tput setaf它tput setab以某种奇怪的语法为区间 0-7、8-15 和 16-255 编码了一个 if-else 分支，也就是说，据我所知，它应该为前 16 种颜色发出传统的转义序列，在您的情况下，这应该意味着即使使用 TERM=xterm-256color，与 TERM=xterm 相比，行为也不会改变。根据您迄今为止收到的输入，我让您从这里进一步调查，例如使用来script记录nethack的输出并使用文本查看器检查它发出了哪些类型的转义序列。