脚本跑到一半挂了，日志里只有一句 “command not found: curl”。后来加了几行检测，脚本就不再傻眼地崩溃了。常见的做法是用 command -v、type、which、hash 之类的手段先探探路，遇到缺东西就给个友善提示或终止。
那次出问题的背景挺普遍：写了个部署脚本，里头直接调用 curl、tar、jq，谁知道在服务器上用 cron 定时跑，环境变量 PATH 被压缩成了极简版，/usr/local/bin 根本不在里头。脚本一开始没检测，报错堆栈很短——就是那句找不到命令。检查过程就是先看 cron 的环境、跑脚本的用户、再手动在机器上执行同样命令，发现交互式 shell 能找到 curl，但 cron 里找不到。把 PATH 明确写到脚本头，顺手加上命令存在性的判断，问题就稳了。
说清楚几个常用办法的用法和坑，这样后来碰到能快速处理。
先讲一个常用、兼容性好的办法：command -v。它是 POSIX 推荐的检查手段，许多 shell 都内建了。用法很直白：if command -v git >/dev/null 2>&1; then …。返回码是关键：找到就 0，找不到就是非 0。好处是调用开销小、脚本搬到别的系统上也更稳。需要注意的是，command -v 输出的是“该如何调用”这个命令，在遇到别名、函数或 shell 内建时，输出可能不是一个绝对路径，所以如果你非得拿到可执行文件的路径，还得额外判断。
type 也是 shell 内建，输出更“详细”：会告知你这是个别名、函数、内建命令还是外部可执行文件。直接在交互式调试时用它很舒服：type ls 会告知你是 alias 还是 /bin/ls。脚本里可以用 type 来做更精细的检查，但要知道不同 shell 输出格式可能略有差异，解析输出要小心。列如你想知道是不是外部文件，type 的输出能给线索，但解析字符串去判断类型比直接用 command -v 更脆弱。
which 是个外部工具，许多系统有，但不是 POSIX 标准。它只在 PATH 指定的目录里找可执行文件，不思考 shell 函数和别名，也不必定能识别 shell 内建。因此它适合在你只关心普通可执行文件、且确信 which 存在的场景用。别依赖它在所有环境都可用，尤其是在最小化容器或精简系统里可能找不到 which。
hash 是个比较另类的选择。bash 等 shell 有哈希表记录曾经定位过的命令位置，hash 命令能查看或利用这张表。用 hash 命令去判断命令是否存在有个问题：如果那条命令之前没被执行过，哈希表里可能没有条目，hash 就会返回非 0，误报“没找到”。所以别把 hash 当做普适的存在性检测器，更多用于性能优化或查看当前 shell 的缓存状态。
举几个实战代码片段，能直接放在脚本头里防守：
最简单也最兼容的一版：
if command -v curl >/dev/null 2>&1; then
:
else
echo “需要 curl，但找不到。请安装或调整 PATH。” >&2
exit 1
fi
检查多个命令，用循环：
need=(curl tar jq)
for cmd in “${need[@]}”; do
if ! command -v “$cmd” >/dev/null 2>&1; then
echo “缺少：$cmd” >&2
exit 1
fi
done
有时候你还想确认得到的是可执行文件的路径，而不是别名或函数。这时可以先用 command -v 获取输出，再判断是否看起来像路径：
p=$(command -v mycmd 2>/dev/null) || p=””
if [ -n “$p” ] && [[ “$p” == */* ]]; then
[ -x “$p” ] && echo “可执行路径 $p”
else
echo “mycmd 存在，但不是简单的可执行文件，可能是别名或函数”
fi
（上面用到的字符串匹配在 sh 下可能不通，按你脚本用的 shell 调整。）
还有个常见坑是 PATH 本身。许多问题不是程序没装，而是脚本运行环境的 PATH 太窄。Cron、systemd、容器、远程执行环境，都会把 PATH 精简。解决办法是在脚本顶部直接设置 PATH，列如：
PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
export PATH
然后再做命令检查。记得把你依赖的目录放进去。
再说一个和权限相关的细节：即便 command -v 找到了一个路径，如果那个文件没有可执行权限，脚本在执行时还是会失败。要确认权限，可以拿到路径后用 [ -x “$path” ] 来检查。只用 command -v 没法确认权限，尤其当输出指向一个脚本或链接时，最好再检查一次。
实战中的定位流程常是这样的：先看日志里的错误提示，确认是找不到命令还是运行时报错；再在同一用户和环境下手动复现；用 command -v、type、which 看看脚本运行时到底能见到哪些命令；如果发现 PATH 问题，先在脚本里把 PATH 写清楚；如果是别名或函数的差异（交互式 shell 有别名、脚本执行环境没有），思考直接调用绝对路径或在脚本里声明所需的功能实现；如果需要跨平台兼容，把检查写成函数用 command -v 实现，尽量少依赖 which 或特定 shell 的特性。
我自己用脚本多年，最常踩的两个坑是：一是不检查就直接调用，二是把脚本放在有严格环境限制的地方运行（像 cron 或 CI），结果路径不同、权限不同，导致“明明机器上装着，脚本还是找不到”。把检查放在开头，再把 PATH 写清楚，能省不少时间。
下面给出一个相对完整的脚本开头模版，能直接拿过去用：
#!/usr/bin/env bash
set -eu
PATH=”/usr/local/bin:/usr/bin:/bin”
export PATH
need=(curl tar jq)
for cmd in “${need[@]}”; do
if ! command -v “$cmd” >/dev/null 2>&1; then
echo “缺失命令：$cmd，安装后重试。” >&2
exit 1
fi
done
# 如果你还想检查可执行文件权限：
p=$(command -v curl 2>/dev/null) || p=””
if [ -n “$p” ] && [[ “$p” == */* ]]; then
if [ ! -x “$p” ]; then
echo “$p 不可执行” >&2
exit 1
fi
fi
用好这些手段，脚本的鲁棒性会强许多。遇到不同系统、不同 shell 时，优先思考 command -v 做兼容性检测；需要辨别别名/函数/内建时用 type；对 PATH 问题保持警惕，最好在脚本里先把环境整清楚。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
