Linux怎么调试Shell脚本_Linux如何使用set -x排查脚本【技巧】-LINUX-PHP中文网

set -x 能立刻看到执行过程，因为它开启shell跟踪模式，将每条实际执行的命令（含展开后的参数）在运行前打印到stderr，输出前缀为+，仅对当前shell生效且不显示注释或空行。

linux怎么调试shell脚本_linux如何使用set -x排查脚本【技巧】

因为 set -x 会开启 shell 的“跟踪模式”，每条实际执行的命令（展开后、带参数值的）都会在运行前自动打印到 stderr。它不分析逻辑，只忠实地回显——所以你看到的，就是 shell 真正拿到并执行的东西。

常见错误现象：脚本看似没输出、卡住或跳过某段逻辑，但加了 set -x 后发现某行根本没执行，或者执行的是 cp file.txt /tmp/ 而不是你以为的 cp "$SRC" "$DST"——说明变量为空或未导出。

全局加 set -x 容易被初始化、环境检测等无关输出淹没。真正要查的，往往只是某段逻辑分支或函数内部。

使用场景：函数调用链深、条件分支多、只怀疑某几行有问题。

在函数开头加 set -x，结尾加 set +x（+ 表示关闭），例如：

my_func() {
    set -x
    cp "$1" "/tmp/"
    [ -f "/tmp/$(basename "$1")" ]
    set +x
}

不是 set -x 失效，而是 shell 执行路径根本没走到那里——比如条件判断失败、函数未被调用、或者脚本被 exit 中断了。

典型表现：set -x 加在 if 块里，但什么都没打印；或只看到部分命令，后续消失。

检查是否提前 exit 或遇到 set -e 导致的非零退出而终止执行
确认变量是否为空导致条件跳过，例如 [ -n "$VAR" ] && { set -x; do_something; set +x; }，若 $VAR 为空，整个块都不会执行
set -x 输出走 stderr，如果脚本重定向了 stderr（如 2>/dev/null），就看不到任何跟踪信息
某些 shell（如 dash）不支持 set -x 的某些变体，优先用 bash -x script.sh 替代

本质一样，都是启用 xtrace，但触发时机和作用域不同：前者是启动时全局开启，后者是运行中动态开关。

性能与兼容性影响：无实质差异，但启动参数方式更可靠，尤其当脚本本身有语法错误、或依赖特定 shebang 时。

bash -x script.sh 会忽略脚本第一行的 #!/bin/sh，强制用 bash 解释，适合调试 bash 特有语法（如 [[、数组）
sh -x script.sh 更贴近真实运行环境（如果脚本声明为 #!/bin/sh），但不支持 bash 扩展
如果脚本用了 exec 替换自身进程（如 exec python3 ...），set -x 在 exec 后失效，而 bash -x 只能跟踪到 exec 前