一、为什么要美化Shell调试输出？
写Shell脚本的人都有过这种体验：脚本跑崩了，输出的错误信息要么只说“这里错了”，要么直接抛一串看不懂的乱码，想定位问题得翻几十行代码找对应位置，折腾半天还找不到到底是哪行出的错。尤其是写稍微复杂点的脚本，比如批量处理文件、部署服务的自动化脚本，里面嵌套了好几个自定义函数，调试的时候根本不知道错误是在函数内部还是外部触发的。
这时候就需要用到Shell自带的调试功能，其中最常用的就是set -x命令，它能在脚本执行每一行代码之前，先把这行代码的内容打印出来，相当于给脚本开了个“实时监控”。但默认的set -x输出有个大问题：只打印代码内容，没有行号，也不知道这行代码是在哪个函数里运行的，找错效率特别低。
为了解决这个问题，我们可以通过两个核心手段来美化调试输出：一是定制PS4变量（Shell里的命令提示符变量），二是用BASH_XTRACEFD把调试输出单独重定向到文件或终端，既不干扰正常的脚本输出，又能拿到清晰的调试信息。
二、核心技术点详解
2.1 什么是PS4？
PS4是Shell里专门给调试功能用的提示符变量，默认值是+。当你开启set -x后，每一行调试输出的开头都会加上这个PS4的值。比如默认情况下，执行set -x; echo 123，输出会是+ echo 123，这里的+就是PS4的默认值。
我们可以通过修改PS4的内容，把行号、函数名、执行时间这些有用的信息加进去，让调试输出一眼就能看懂。PS4里支持很多特殊的转义字符，用来获取不同的上下文信息，常用的有：
${LINENO}：当前执行代码的行号${FUNCNAME[0]}：当前所在的函数名（如果不在函数里，值为空）${BASH_SOURCE[0]}：当前脚本的文件名\t：当前的时间戳（精确到秒）
2.2 什么是BASH_XTRACEFD？
BASH_XTRACEFD是Bash 4.1及以上版本新增的一个环境变量，用来指定调试输出的文件描述符。默认情况下，set -x的调试输出会和脚本的正常输出（比如echo、printf的内容）混在一起，要找调试信息得翻半天。
通过给BASH_XTRACEFD赋值一个自定义的文件描述符，我们可以把调试输出重定向到单独的终端、文件或者管道里，让正常输出和调试输出完全分开，互不干扰。比如我们可以开一个新的终端窗口，专门用来显示调试信息，这样就能一边看脚本的正常运行结果，一边实时看调试的追踪信息。
三、完整示例演示
3.1 示例准备
所有示例统一使用Shell（Bash）技术栈，需要满足的前置条件：
- 系统安装Bash 4.1及以上版本（可以用
bash --version查看版本号） - 有两个独立的终端窗口（用来演示调试输出的分离）
3.2 基础示例：给调试输出加行号和函数名
这个示例用来演示如何修改PS4，让调试输出包含行号、函数名和时间戳，适合单终端调试的场景。
#!/bin/bash
# 这是一个测试脚本，用来演示PS4的定制效果
# 第一步：开启调试模式，设置PS4
set -x # 开启调试追踪
# 定制PS4：格式为【时间戳】脚本名:行号:函数名: 代码内容
# 注意：PS4里的变量要用单引号包裹，否则会在赋值时就被解析，而不是执行时解析
PS4='[\t] ${BASH_SOURCE[0]}:${LINENO}:${FUNCNAME[0]}: '
# 自定义函数1：用来测试函数内部的调试输出
function test_func1 {
local var1="我是函数1的变量"
echo $var1 # 打印函数内的变量
test_func2 # 调用另一个函数
}
# 自定义函数2：嵌套调用的函数
function test_func2 {
local var2="我是函数2的变量"
echo $var2 # 打印函数内的变量
# 故意写一个错误的命令，用来测试错误时的调试输出
non_existent_command
}
# 主逻辑：调用自定义函数
echo "脚本开始执行"
test_func1
echo "脚本执行结束"
把上面的代码保存为test_debug.sh，然后给它加执行权限：
chmod +x test_debug.sh
执行脚本后，你会看到类似下面的输出：
[10:00:00] test_debug.sh:16:: echo 脚本开始执行
脚本开始执行
[10:00:00] test_debug.sh:17:: test_func1
[10:00:00] test_debug.sh:9:test_func1: local var1=我是函数1的变量
[10:00:00] test_debug.sh:10:test_func1: echo 我是函数1的变量
我是函数1的变量
[10:00:00] test_debug.sh:11:test_func1: test_func2
[10:00:00] test_debug.sh:14:test_func2: local var2=我是函数2的变量
[10:00:00] test_debug.sh:15:test_func2: echo 我是函数2的变量
我是函数2的变量
[10:00:00] test_debug.sh:17:test_func2: non_existent_command
test_debug.sh: line 17: non_existent_command: command not found
[10:00:00] test_debug.sh:18:: echo 脚本执行结束
脚本执行结束
可以看到，每一行调试输出都包含了时间戳、脚本名、行号和函数名，比如[10:00:00] test_debug.sh:10:test_func1: echo 我是函数1的变量，一眼就能知道这行代码是在test_func1函数里的第10行执行的，找错的时候直接跳转到对应行号就行，效率比默认的调试输出高很多。
3.3 进阶示例：用BASH_XTRACEFD分离调试输出
这个示例用来演示如何用BASH_XTRACEFD把调试输出和正常输出分开，适合需要实时查看调试信息但不想干扰正常输出的场景。
首先，开两个终端窗口，我们把第一个终端叫做“主终端”，用来运行脚本和看正常输出；第二个终端叫做“调试终端”，用来专门看调试输出。
第一步：在调试终端里，先执行一个命令，用来获取当前终端的设备文件路径，比如：
tty
执行后会输出类似/dev/pts/2的路径，记住这个路径，后面要用到。
第二步：在主终端里，编写如下脚本：
#!/bin/bash
# 这是一个测试脚本，用来演示BASH_XTRACEFD的效果
# 第一步：开启调试模式，设置PS4
set -x # 开启调试追踪
# 定制PS4，包含行号、函数名、脚本名
PS4='[调试追踪] ${BASH_SOURCE[0]}:${LINENO}:${FUNCNAME[0]}: '
# 第二步：设置BASH_XTRACEFD，把调试输出重定向到调试终端
# 这里的/dev/pts/2要替换成你自己调试终端的tty路径
exec 200>/dev/pts/2 # 打开一个自定义的文件描述符200，指向调试终端
BASH_XTRACEFD=200 # 把调试输出绑定到文件描述符200
# 自定义函数1
function process_file {
local file=$1
echo "正在处理文件：$file" # 正常输出，会显示在主终端
# 故意写一个错误的操作，用来测试调试输出
cat $file # 尝试读取一个可能不存在的文件
}
# 自定义函数2
function batch_process {
echo "开始批量处理文件" # 正常输出
# 遍历当前目录下的所有文件
for file in *; do
process_file $file
done
echo "批量处理结束" # 正常输出
}
# 主逻辑
echo "脚本启动" # 正常输出
batch_process
echo "脚本结束" # 正常输出
把上面的代码保存为test_xtrace.sh，加执行权限后在主终端执行：
chmod +x test_xtrace.sh
./test_xtrace.sh
这时候你会发现，主终端里只会显示脚本的正常输出，比如：
脚本启动
开始批量处理文件
正在处理文件：test_debug.sh
#!/bin/bash
...（test_debug.sh的内容）
正在处理文件：test_xtrace.sh
#!/bin/bash
...（test_xtrace.sh的内容）
批量处理结束
脚本结束
而调试终端里则会显示所有的调试追踪信息，比如：
[调试追踪] test_xtrace.sh:23:: echo 脚本启动
[调试追踪] test_xtrace.sh:24:: batch_process
[调试追踪] test_xtrace.sh:16:batch_process: echo 开始批量处理文件
[调试追踪] test_xtrace.sh:19:batch_process: for file in test_debug.sh test_xtrace.sh
[调试追踪] test_xtrace.sh:20:batch_process: process_file test_debug.sh
[调试追踪] test_xtrace.sh:10:process_file: local file=test_debug.sh
[调试追踪] test_xtrace.sh:11:process_file: echo 正在处理文件：test_debug.sh
[调试追踪] test_xtrace.sh:13:process_file: cat test_debug.sh
...（以此类推）
这样一来，正常输出和调试输出完全分开，不会互相干扰，找错的时候直接看调试终端就行，非常方便。
四、应用场景分析
这两个技术的组合，最适合以下几种场景：
- 复杂Shell脚本的开发调试：比如部署脚本、批量处理脚本、定时任务脚本，这些脚本往往嵌套了多个函数，逻辑复杂，需要清晰的调试信息来定位问题。
- 线上问题排查：线上出问题时，开启调试功能后，把调试输出重定向到专门的日志文件，既不会干扰线上业务的正常输出，又能拿到完整的追踪信息，方便事后排查。
- 团队协作开发：多人开发同一个Shell脚本时，清晰的调试输出能让团队成员快速理解脚本的执行流程，减少沟通成本。
- 教学和培训：给新手讲解Shell脚本的执行流程时，带行号和函数名的调试输出能让新手快速理解代码的执行顺序和函数调用关系。
五、技术优缺点分析
5.1 优点
- 零成本实现：不需要安装任何额外的工具，只需要修改PS4和BASH_XTRACEFD两个变量，就能实现清晰的调试输出，所有支持Bash的系统都能直接使用。
- 完全自定义：PS4的内容可以根据自己的需求定制，比如可以加执行时间、进程ID、变量值等，只要是Shell支持的特殊字符，都能加进去。
- 分离输出：通过BASH_XTRACEFD可以把调试输出和正常输出完全分开，不会干扰脚本的正常运行，适合线上环境使用。
- 兼容性好：只要是Bash 4.1及以上版本都支持，大部分现代Linux系统（比如CentOS 7及以上、Ubuntu 14.04及以上）都满足这个版本要求。
5.2 缺点
- 依赖Bash版本：BASH_XTRACEFD是Bash 4.1新增的功能，低版本的Bash（比如CentOS 6里的Bash 4.0）不支持，需要升级Bash版本才能使用。
- 调试输出量较大：开启
set -x后，脚本的每一行代码都会被打印出来，对于代码量很大的脚本，调试输出会非常多，需要配合日志分割工具来管理。 - 不能调试外部命令：PS4和BASH_XTRACEFD只能追踪Shell脚本内部的代码执行，对于脚本调用的外部命令（比如cat、ls、grep等）的内部执行流程，无法追踪。
六、注意事项
- PS4的变量要加单引号：如果给PS4赋值的时候用双引号，那么变量（比如${LINENO}、${FUNCNAME}）会在赋值的时候就被解析，而不是在代码执行的时候解析，这样所有调试输出的行号和函数名都会是一样的，达不到预期效果。
- BASH_XTRACEFD的文件描述符要大于等于3：Shell默认的文件描述符0（标准输入）、1（标准输出）、2（标准错误）已经被占用，所以自定义的文件描述符要从3开始，一般选10以上的数字，避免和其他自定义的文件描述符冲突。
- 线上环境使用要谨慎：开启
set -x会打印所有的代码执行内容，包括变量值、参数等，如果脚本里有敏感信息（比如密码、密钥），可能会被泄露到调试日志里，所以线上环境使用前要确认没有敏感信息，或者把敏感信息的打印过滤掉。 - 调试结束后要关闭调试模式：脚本调试完成后，要把
set -x和BASH_XTRACEFD的设置去掉，避免调试输出干扰正常的脚本运行，或者泄露敏感信息。
七、文章总结
定制PS4和使用BASH_XTRACEFD是Shell脚本调试中非常实用的两个技巧，它们能把默认的模糊调试输出，变成清晰的、带行号和函数名的追踪信息，大大提高找错的效率。通过修改PS4，我们可以根据自己的需求定制调试输出的格式，通过BASH_XTRACEFD，我们可以把调试输出和正常输出分开，互不干扰。
这两个技巧的组合，既适合开发阶段的调试，也适合线上问题的排查，只要掌握了它们的使用方法，就能让Shell脚本的调试变得简单很多，再也不用为找错而头疼。
Comments