bash-completion的补全深度由各命令对应的补全函数自行控制，而非统一参数调控；其粒度取决于函数是否调用_filedir/_command等辅助函数、是否设置COMP_WORDBREAKS等上下文变量，以及对语义上下文的解析能力。
bash-completion 的补全深度由什么控制？
补全深度不是由某个“联想词深度”参数统一调控的，而是由每个命令对应的补全函数自己决定。比如 git 补全能到子命令（git checkout <Tab> → 列出分支），而 ls 默认只补路径，不展开文件类型过滤——这取决于补全脚本里是否调用了 _filedir、_command 这类底层辅助函数，以及是否设置了 COMP_WORDBREAKS 或 COMP_LINE 等上下文变量。
如何修改特定命令（如 conda）的补全行为？
以 conda 为例，它的补全逻辑由 conda shell completions bash 生成，但默认不包含“深度联想”（比如输入 conda activate py<Tab> 不会自动过滤出所有含 py 的环境名）。要增强它：
- 确认已启用官方补全：
source <(conda shell completions bash)，且该行已写入~/.bashrc - 检查补全函数是否被覆盖：运行
complete -p conda，输出应为类似complete -F _conda_auto_dev conda；若显示-o default，说明 fallback 到了基础文件补全，需重载 - 手动增强环境名补全：在
~/.bash_completion末尾追加
_<code>conda_activate</code>() {
local cur="${COMP_WORDS[COMP_CWORD]}"
COMPREPLY=($(conda env list --name-only 2>/dev/null | grep "^$cur"))
}
complete -F _conda_activate "conda activate"
这样 conda activate py<Tab> 就只会匹配以 py 开头的环境名，而非列出全部。
为什么 Terminator 里补全响应慢或不一致？
Terminator 是多进程终端复用器，每个标签页是独立的 Bash 进程，补全函数必须在每个会话中重新加载。常见问题包括：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
~/.bash_completion被 source 但未执行complete -F注册（尤其在非交互式子 shell 中） -
$TERMINATOR_UUID环境变量存在时，某些补全脚本会跳过初始化（例如旧版bash-completion1.x） - 补全函数依赖外部命令（如
kubectl、aws），而这些命令在某分会话中 PATH 不全，导致补全卡住或失败
验证方式：新开 Terminator 标签页，运行 complete -p conda 和 type _conda_activate，两者都应有输出；若无，说明补全未生效，需检查 ~/.bashrc 是否在每次新会话中完整执行。
自定义补全时最容易忽略的兼容性点
补全函数不是纯 Bash 脚本，它运行在 COMP_* 变量约束的上下文中，几个关键限制常被忽略：
-
COMP_WORDS是分词后的数组，但分词依据是COMP_WORDBREAKS（默认含=:），所以git -c core.editor=vim<Tab>会被截断，补全函数需手动解析 -
COMPREPLY必须是纯字符串数组，不能含空格或换行；想补带空格的路径，得用printf %q转义 - Bash 4.4+ 支持
compopt -o nospace防止补全后自动加空格，但 Ubuntu 22.04 默认 Bash 5.1，而 20.04 是 5.0 —— 跨版本写补全函数时要避开compopt或做版本判断
补全深度本质上是函数实现粒度的问题，不是开关一开就变深。真正影响体验的，往往是补全函数是否处理了当前光标位置的语义上下文，而不是单纯增加候选数量。
