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