如何安全地探测终端当前背景色？

用 OSC 11 查询（\x1b]11;?\x07）—— 返回背景色，形如 rgb:RRRR/GGGG/BBBB。DECRQSS 本身查询 SGR / 模式状态，不查 RGB。查询/应答模式：写入查询，对 stdin 设 100–200 ms 读超时，解析应答（\x1b]11;rgb:1e1e/1e1e/1e1e\x07 或以 \x1b\\ 结束），再算亮度挑出与输出对比足够的前景色。不支持 OSC 11 的终端 —— 较老的 xterm、2021 前的 Apple Terminal.app、Linux console —— 会静默丢弃查询并触发超时；该情况下回落到 $COLORFGBG（部分 shell / 终端会设）或假定暗主题。

哪些终端会响应 DECRQSS？

xterm（首创者）、kitty、WezTerm、foot、Alacritty、Ghostty、Windows Terminal ≥ 1.21 都会对 DECRQSS 的标准子集作出应答：SGR（\x1bP$qm\x1b\\）、光标形状（\x1bP$q q\x1b\\）、DECSTBM 滚动区域和少量 DEC 私有模式。Apple Terminal.app、gnome-terminal、konsole、Linux console / fbcon、screen 4.x *不*实现 DECRQSS —— 查询被静默丢弃。务必设读超时（标准 100–200 ms），并备好基于 $TERM 的硬编码回退表；切勿假定应答必至。

DECRQSS — 请求选区或设置（DCS $ q ... ST）

请求终端报告任一 SGR / 模式 / 边距 / 光标形状当前值 —— DCS 通用查询。

字节形式

涵盖所有常见的字符串字面量写法，方便正反查找。

\\x1b[\x1bP$q\x1b\\

\\033[\033P$q\033\\

\\e[\eP$q\e\\

ESC [ESC P $ q ESC \

hex1b 50 24 71 ... 1b 5c

说明

Request Selection or Setting。中间字节 $（0x24）、末字节 q（0x71）的 DCS 帧；体  指明要查询的设置。常见探测：\x1bP$qm\x1b\\ 查询当前 SGR 属性（终端以 \x1bP1$rm\x1b\\ 回报当前颜色/样式栈）；\x1bP$q r\x1b\\（字面 $ q SP r）查询 DECSTBM 滚动区域上下边距；\x1bP$q" p\x1b\\ 查询 DECSCL 一致性级别；\x1bP$q" q\x1b\\ 查询 DECSCA 字符保护；\x1bP$q q\x1b\\（SP q）查询当前 DECSCUSR 光标形状。回复同样是 DCS 帧 —— 首字节 1（有效且支持）或 0（请求无效），随后 $r、所请求的设置字节、ST。现代程序在启动探测时使用 DECRQSS，以便退出时恢复终端的原有状态 —— vim 的 t_RV 自动检测、bat 的语法主题选择、kitty kitten themes 都依赖它。

规范出处: xterm-ctlseqs (DECRQSS, DCS $ q Pt ST)

示例

bash

# Ask for the current SGR attributes; reply lands on stdin in raw mode.\nstty -echo raw min 0 time 5\nprintf '\033P$qm\033\\'; IFS= read -r -t 1 -d '\\' REPLY; stty sane\necho "DECRQSS m reply: $REPLY"

python

import sys; sys.stdout.write('\x1bP$qm\x1b\\\\')   # reply arrives on stdin

fmt.Print("\x1bP$qm\x1b\\\\")   // request current SGR

javascript

process.stdout.write('\x1bP$qm\x1b\\\\')   // request current SGR; read process.stdin

printf("\x1bP$qm\x1b\\\\"); fflush(stdout); /* read DCS reply from stdin */

在哪里用到

实际会发出该序列的工具——把抽象字节锚定到你已经用过的命令上。

vim, neovim — terminal capability probe (`t_RV`, `&background` detection)vim 启动时发 `\x1bP$qm\x1b\\` 读取当前 SGR 状态，发 `\x1bP$q q\x1b\\`（`SP q`）读取光标形状 —— 因此 `:q!` 退出后，光标回到你原来的竖线 / 方块 / 下划线，而不是 vim 硬编码的默认值
kitty `kitten themes` and `kitten icat` probe`themes` kitten 在改动运行时配置前用 DECRQSS 读取当前 SGR 调色板和光标形状参数 —— `kitten themes solarized-light` 切换能干净地翻转 SGR 映射，而不会覆盖自定义的闪烁方块光标
bat — auto-theme picker for `--theme=auto``bat --theme=auto` 用 `\x1bP$qm\x1b\\` 探测当前 SGR；若没有明确的默认背景信号，再用 OSC 11 + DECRQSS `" p`（一致性级别）决定切浅色或深色语法主题，而不是从 `$TERM` 猜测
tmux passthrough wrapper (`allow-passthrough on`)tmux 默认剥离 DCS —— 启用 `allow-passthrough on` 后，tmux 内的 vim 可把 `\x1bP$qm\x1b\\` 传给外层终端，并把应答路由回来；内层编辑器看到的是*外层*终端的状态，而非 tmux 合成的（tmux 没有光标形状概念）
Ghostty / WezTerm / xterm feature-detection scripts`terminal-capabilities.sh`、`vim-terminfo-probe` 等 shell 助手在会话开始时用 DECRQSS 走遍每条 SGR / DECSCUSR / DECSTBM 设置，把应答写入 `~/.cache/terminal-state.json`；下游程序读取该文件而非重新探测 —— 把吵闹的多轮往返握手变成一次缓存读

常见问题

针对这条序列，开发者真正会去搜索的问题的简短回答。

如何安全地探测终端当前背景色？: 用 OSC 11 查询（\x1b]11;?\x07）—— 返回背景色，形如 rgb:RRRR/GGGG/BBBB。DECRQSS 本身查询 SGR / 模式状态，不查 RGB。查询/应答模式：写入查询，对 stdin 设 100–200 ms 读超时，解析应答（\x1b]11;rgb:1e1e/1e1e/1e1e\x07 或以 \x1b\\ 结束），再算亮度挑出与输出对比足够的前景色。不支持 OSC 11 的终端 —— 较老的 xterm、2021 前的 Apple Terminal.app、Linux console —— 会静默丢弃查询并触发超时；该情况下回落到 $COLORFGBG（部分 shell / 终端会设）或假定暗主题。
哪些终端会响应 DECRQSS？: xterm（首创者）、kitty、WezTerm、foot、Alacritty、Ghostty、Windows Terminal ≥ 1.21 都会对 DECRQSS 的标准子集作出应答：SGR（\x1bP$qm\x1b\\）、光标形状（\x1bP$q q\x1b\\）、DECSTBM 滚动区域和少量 DEC 私有模式。Apple Terminal.app、gnome-terminal、konsole、Linux console / fbcon、screen 4.x *不*实现 DECRQSS —— 查询被静默丢弃。务必设读超时（标准 100–200 ms），并备好基于 $TERM 的硬编码回退表；切勿假定应答必至。

常见错写 / 易混形

开发者常从 Stack Overflow 粘贴的错误写法 —— 看起来对其实不对，附上规范的正确写法。

\x1bP$qm\x1b (only ESC, missing the \\ of ST)\x1bP$qm\x1b\\ (ESC \\ = ST, the proper DCS terminator)
每条 DCS 帧必须以 ST 终止 —— \x1b\\（ESC 后跟 \，十六进制 1b 5c）—— 不能只发 ESC。少了尾部 \\，终端的 DCS 解析器停留在 string 状态，静默把后续字节（你的 shell 提示符、下一程序的输出、任何东西）追加到 DCS 负载，直到看到 ST。症状：终端看似冻结 / 一次按键无响应，然后一段文本消失（被吃进未完结的 DCS 体）。xterm-strict 与 Ghostty 严格强制 ST；kitty / wezterm 对 OSC 容忍 BEL 兜底，但对 DCS *不*容忍。始终发完整 2 字节 ST。
read DECRQSS reply with a fixed read(fd, buf, 16) and bailread until ST is seen — typical reply lengths range 8–64 bytes (SGR state stack can be longer); use a timeout-bounded incremental read
DECRQSS 回复是变长 DCS 帧：\x1bP1$r<body>\x1b\\。SGR（$qm 查询）的 <body> 列出当前 SGR 栈 —— 重置后为 0，或叠了真彩 + 调色板色后是 0;1;38;5;196;48;2;30;30;30 等。固定 16 字节 read 会截断栈中间，解析器看到残帧，*下个*程序的 stdin 以这些孤儿尾字节开头。更糟的是回复可能 100–1000 ms 才到（网络终端、tmux DCS 透传）。健壮模式：把 stdin 设非阻塞、超时 200–500 ms、按 64 字节块读、累积直到看到 ST（\x1b\\）或超时 —— 与 XTGETTCAP、DECRQM 回复处理同形。
\x1bP+qm\x1b\\ (intermediate + from XTGETTCAP) to request current SGR\x1bP$qm\x1b\\ (intermediate $, hex 0x24)
DCS 中间字节区分请求*族*：$（0x24）是 DECRQSS（请求设置当前值，回复体 $r<value>）；+（0x2b）是 XTGETTCAP（按十六进制名请求 terminfo 能力，回复体 +r<hexname>=<hexvalue>）。两者回复形态、负载编码、终端支持都不同 —— kitty / wezterm / ghostty 两者都支持，alacritty 只支持 XTGETTCAP 不支持 DECRQSS，screen 都不支持。发 \x1bP+qm\x1b\\ 让终端去查名为 m 的 terminfo 能力（不存在），回复 \x1bP0+rm\x1b\\ —— 「未识别能力」—— 不是你要的 SGR 状态。

终端支持

xterm: 支持
Linux console (fbcon): 不支持
macOS Terminal.app: 不支持
iTerm2: 部分
Windows Terminal: 部分
cmd.exe / ConPTY: 不支持
kitty: 支持
alacritty: 不支持
WezTerm: 支持
Ghostty: 支持
GNOME Terminal: 部分
Konsole: 部分
tmux: 部分
GNU screen: 不支持

xterm	Linux console (fbcon)	macOS Terminal.app	iTerm2	Windows Terminal	cmd.exe / ConPTY	kitty	alacritty	WezTerm	Ghostty	GNOME Terminal	Konsole	tmux	GNU screen
支持	不支持	不支持	部分	部分	不支持	支持	不支持	支持	支持	部分	部分	部分	不支持

在家族食谱中

DCS 食谱 · 3. 向终端提问 —— DECRQSS、terminfo cap、DECRQTSR、DECRQUPSS、光标样式

字节形式

说明

示例

在哪里用到

相关误区

常见问题

终端支持

相关序列

在家族食谱中