PS1配色失效主因是ANSI转义序列未用[和]包裹，导致bash误判宽度；ls无颜色则多因LS_COLORS未加载或~/.bashrc缺eval "$(dircolors -b)"。
PS1 配色改了没生效？ls 颜色突然没了？别急着重装终端——90% 的问题出在 ANSI 转义序列没闭合、LS_COLORS 未加载，或 ~/.bashrc 里漏了 eval "$(dircolors -b)"。
为什么 echo -e "\033[31m红色\033[0m" 有时不生效
根本原因是终端对转义序列的解析依赖于是否启用「解释转义字符」模式。直接写进脚本或变量时容易被 shell 当作普通字符串处理。
-
echo -e是必须的：不加-e，\033就是字面量，不会触发颜色 -
\033[0m必须显式结尾：漏掉它会导致后续所有输出（包括命令提示符、下一行ls）都保持前一个颜色样式 - 在
PS1中要用\[和\]包裹转义序列：否则 bash 会错误计算提示符宽度，导致光标错位、换行异常 - 示例正确写法：
PS1='\[\033[1;32m\]\u@\h:\[\033[34m\]\w\[\033[0m\]\$ '
ls 颜色失效的三个常见原因
ls --color=auto 默认开启颜色，但实际是否显示取决于环境变量和配置文件是否就位。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
LS_COLORS为空或未导出：运行echo $LS_COLORS，若无输出，说明dircolors没加载 - 没在
~/.bashrc中调用eval "$(dircolors -b)"：这是激活~/.dircolors文件的关键一步 -
LS_COLORS被覆盖：比如在~/.bashrc后半部分又写了export LS_COLORS=空值，会清空之前所有规则 - 快速修复：
dircolors -p > ~/.dircolors && echo 'eval "$(dircolors -b ~/.dircolors)"' >> ~/.bashrc && source ~/.bashrc
用 tput 替代硬编码 ANSI 更可靠
不同终端对 \033[31m 支持一致，但某些嵌入式或老旧终端可能不识别复合样式（如 \033[1;4;31m）。tput 查询当前终端能力，生成适配序列。
-
RED=$(tput setaf 1)：获取红色前景（比\033[31m更健壮） -
BOLD=$(tput bold)：获取加粗指令（不是所有终端都支持\033[1m） -
RESET=$(tput sgr0)：安全重置，等价于\033[0m，但兼容性更好 - 组合使用：
echo "${RED}${BOLD}ERROR${RESET}: file not found" - 注意：
tput在非交互式 shell（如 cron 脚本）中可能返回空，需加判断：[ -t 1 ] && RED=$(tput setaf 1)
PS1 颜色配置最容易踩的坑
改完 PS1 发现输入长命令时文字重叠、光标跳到行首左边——八成是转义序列没用 \[ \] 包裹。
-
\[和\]告诉 bash：括起来的内容不占屏幕宽度（即纯控制字符），否则 bash 会把\033[32m算作 5 个可见字符，导致行编辑错乱 - 错误写法：
PS1="\033[32m\u@\h\033[0m:\w\$ "→ 光标定位失准 - 正确写法：
PS1="\[\033[32m\]\u@\h\[\033[0m\]:\w\$ " - 别用
\e代替\033：虽然等价，但某些老版本 bash 解析不稳定，坚持用\033 - 调试技巧：临时加
echo "$PS1" | cat -A查看不可见字符是否完整
真正麻烦的不是记不住颜色代码，而是改完配置后不知道该 reload 哪个文件、该检查哪个变量。每次怀疑颜色失效，先跑一遍 echo $LS_COLORS 和 shopt login_shell，比重装终端快得多。
