探索命令的世界

输入 printf、cd 或 python时，我们往往顺手把它叫作“一个命令”。这个说法交流起来没问题，但一到排错环节就不够了：同一个名称可以同时是别名、Shell 函数、Bash 内建命令，还可以在 PATH 的多个目录中出现外部程序。

所以，“这个命令在哪里”不一定是个路径问题。更准确的问法是：当前 Bash 会如何解释这个名称，最终会执行哪一层？

本篇就围绕这个问题展开。我们会把 type、command -v、PATH、hash、help、man、info 和错误状态串成一套可复用的调查方法。

一个命令名背后可以藏着什么

先别急着找路径。在 Bash 的语境中，一个出现在命令位置的词，至少可能落入下面几类。

“外部程序”也不等于“机器码二进制”。它可以是 ELF 可执行文件，也可以是以 shebang 开头的 Shell、Python 或其他脚本。Shell 找到路径后，内核还要检查权限和文件格式，脚本则还依赖 shebang 指向的解释器。

同名候选会层层叠在一起

以 printf 为例，Bash 通常有一个内建 printf，系统也可能安装 /usr/bin/printf。如果当前会话再定义一个同名函数，一个名称就有了三层候选：

printf () {
  builtin printf '[function] %s\n' "$*"
}
 
type -a printf

可以看到类似的结果：

printf is a function
printf ()
{
    builtin printf '[function] %s\n' "$*"
}
printf is a shell builtin
printf is /usr/bin/printf
printf is /bin/printf

type -a 的价值就在这里：它不在找到第一个答案后停止，而是继续告诉你后面还有什么同名实现。反过来，只查一个文件路径，很容易把真正会先执行的函数或内建层漏掉。

内建命令不只是“跑得快”

常见说法是“内建命令不需要从磁盘加载，所以更快”。这没有解释最根本的差异：有些动作必须修改当前 Shell 进程的状态。

cd 修改工作目录，export 修改传给后续子进程的环境，alias 修改交互解析表，jobs 读取当前 Shell 的作业状态。如果让一个独立外部进程执行 cd，它最多改变自己的目录；子进程一退出，父 Shell 仍然留在原处。

反过来，外部程序有自己的进程边界。它的普通变量、工作目录变化和大部分运行时状态不会直接改写父 Shell。这个边界比“快几毫秒”更重要。

图：“命令”是当前 Shell 对一个名称的解析结果，不是天然等同于某个文件。

Bash 到底怎样决定执行谁

理解优先级时，要先分清两个阶段：读取与解析，以及命令查找与执行。别名展开发生在前一阶段；函数、内建和 PATH 候选的选择发生在后一阶段。

在 Bash 普通模式下，可以先用这条主线理解：

识别 Shell 语法与关键字
        ↓
如果是符合条件的未引用命令词，展开别名
        ↓
查找同名 Shell 函数
        ↓
查找 Bash 内建命令
        ↓
检查 Bash 命令路径缓存
        ↓
按 PATH 从左到右搜索外部程序

别名在“执行前”已经改写了输入

别名不是一个参与 PATH 搜索的小程序。Bash 在读取一个符合别名展开位置的未引用词时，会用别名值替换它，然后继续解析替换后的内容。

alias ll='ls -alF'
ll /tmp

这可以理解为 Bash 先看到 ls -alF /tmp，然后再对 ls 做后续命令查找。因此，“别名和函数谁优先”这句话如果不分阶段就容易含糊：别名先改写命令词，替换后的新名称才进入函数、内建和外部程序查找。

引号或反斜杠可以阻止这个词的别名展开，例如 \ls。但这只是跳过别名，不代表绕过同名函数或内建。要精确选实现，应使用 command、builtin 或显式路径。

函数、内建、缓存和 PATH 负责后续选择

别名展开完成后，如果命令名不含 /，Bash 普通模式先查同名函数，再查内建命令。两者都没找到时，才进入外部程序路线。

Bash 会为已查找过的外部命令记住完整路径。缓存命中时，它可以不重新遍历整个 PATH。没有缓存时，它按 PATH 从左到右搜索。

图：别名展开属于读取阶段，函数、内建与外部程序属于后续命令查找。

你可以用三种显式写法选择实现：

command printf '%s\n' 'skip function lookup'
builtin printf '%s\n' 'choose the Bash builtin'
/usr/bin/printf '%s\n' 'choose this exact file'

• command NAME 抑制 Shell 函数查找，然后按内建或标准命令路线处理。
• builtin NAME 明确要求 Bash 内建实现；如果该名称不是内建，它会失败。
• 完整路径包含 /，Bash 不再为它搜索 PATH，而是直接尝试该路径。

如果命令词本身含 /，逻辑会立即分叉。./tool、../bin/tool 和 /opt/course/bin/tool 都是路径，不会去 PATH 里找别的 tool。这也是运行当前目录程序时要写 ./tool 的原因。

不建议为了省掉 ./ 就把 . 加进 PATH。当前目录的内容会随 cd 变化，一个意外出现的 ls、git 或拼写诱饵文件就可能改变执行结果。显式的 ./tool 既表达意图，也避免让所有名称查找都受当前目录影响。

用 type 和 command 可靠地确认来源

排查命令来源时，我建议把 type 和 command -v 当成主力，把 which 当成某些环境里的外部路径辅助工具。

在一次隔离环境中，probe 同时存在于两个 PATH 目录。查询结果是：

$ type -a probe
probe is /tmp/welearn-ch05/bin-a/probe
probe is /tmp/welearn-ch05/bin-b/probe
 
$ type -t probe
file
 
$ type -P probe
/tmp/welearn-ch05/bin-a/probe
 
$ command -v probe
/tmp/welearn-ch05/bin-a/probe

对 cd 的对比更能说明问题：

$ type -a cd
cd is a shell builtin
 
$ command -v cd
cd
 
$ which cd
$ printf 'status=%s\n' "$?"
status=1

which cd 失败不等于 cd 不存在，只表示这个 which 实现没有在 PATH 中找到同名文件。当问题是“Bash 实际会怎样解释”时，这个结果显然不完整。

PATH 顺序、执行权限与命令缓存

PATH 不是“系统安装了哪些命令”的数据库。它只是一串用冒号分隔的目录，为不含 / 的外部命令名提供有序搜索范围。

printf '%s\n' "$PATH"

一个简化结果可能是：

/home/learner/.local/bin:/usr/local/bin:/usr/bin:/bin

PATH 的左右顺序就是优先级

如果上面四个目录里都出现同名 report，Shell 首先选择 /home/learner/.local/bin/report。这不代表其他文件被删除了，只是它们被更靠前的候选遮蔽。

type -a report

可以用来列出后面的同名候选。如果只想临时调整一条命令的搜索范围，可以为它设置单次环境：

PATH="/opt/course/bin:/usr/bin:/bin" command -v report

持久修改 PATH 时要先回答两个问题：这个目录由谁写入？放到前面后会遮蔽哪些系统命令？将可被不可信用户写入的目录放在前面，可能让同名文件抢先执行。

找到路径之后，还有执行条件要过

外部文件能否启动，至少要继续检查：

1. 路径中每一层目录是否允许搜索，也就是目录的执行权限。
2. 目标文件对当前身份是否有执行位。
3. 文件系统挂载是否允许执行；noexec 可以在文件有 x 时仍拒绝直接启动。
4. 文件是否是可识别的可执行格式，或有正确 shebang。
5. shebang 指向的解释器是否存在且可调用。

隔离实验中，一个模式为 0644 的 blocked 文件出现在 PATH 前置目录：

$ command -v blocked
/tmp/welearn-ch05/bin-a/blocked
$ printf 'lookup=%s\n' "$?"
lookup=0
 
$ blocked
bash: /tmp/welearn-ch05/bin-a/blocked: Permission denied
$ printf 'run=%s\n' "$?"
run=126

command -v 告诉我们 Bash 会尝试哪个路径，实际启动则因没有执行位失败。这正好把两个阶段分开了。

Shell 通常用两个特殊状态表达命令查找/调用失败：

图：命中名称、能否调用、程序自身能否完成任务，是三个不同问题。

Bash 的 hash 可能记着过期路径

为了避免每次都遍历 PATH，Bash 会缓存部分外部命令的完整路径。可用下面的命令观察和管理：

hash                 # 列出已记住的命令
hash -t probe        # 只查 probe 的缓存路径
hash -d probe        # 删除 probe 这一项
hash -r              # 清空所有命令路径缓存

隔离实验的顺序是：

PATH=/tmp/welearn-ch05/bin-a:/tmp/welearn-ch05/bin-b:/usr/bin:/bin
 
$ probe
PROBE_A
$ hash -t probe
/tmp/welearn-ch05/bin-a/probe
 
  # 移除 bin-a/probe，bin-b/probe 仍然存在
$ probe
bash: /tmp/welearn-ch05/bin-a/probe: No such file or directory
$ printf 'status=%s\n' "$?"
status=127
 
$ hash -r
$ probe
PROBE_B

第二个 probe 并没有立即接管，因为 Bash 还在尝试缓存的 A 路径。hash -r 后重新搜索，才命中 B。对 PATH 赋值也会让 Bash 清空命令路径缓存。

图：文件被替换或移除不一定会让旧缓存当场改道，排查时要显式检查 hash。

真正的排查要把“名称解析”、“文件可调用”和“程序运行成功”分开。command -v 属于第一层，权限、挂载和解释器属于第二层，程序自己定义的退出状态属于第三层。混在一起时，“可以找到为什么还失败”就会看起来很奇怪。

别名与函数要用在合适的边界里

别名和 Shell 函数都能让我们创造新名称，但它们解决的问题不同。别名更像交互输入的文本缩写；函数则是在当前 Shell 中运行的可参数化命令组。

别名适合短、固定、面向交互的替换

一个边界清楚的别名可以是：

alias ll='ls -alF'
alias grep='grep --color=auto'

它们的价值是减少重复输入，并且不试图根据参数改变控制流。下面几条边界要记住：

• Bash 别名主要展开简单命令的第一个未引用词，它不提供函数那样的 $1、$2。
• 非交互 Bash 默认不展开别名，除非显式开启 expand_aliases。因此脚本不应默认依赖交互别名。
• Bash 在读取命令时展开别名。把别名定义和期望立即受影响的命令塞进同一个已经解析的命令块，结果可能与直觉不同。
• 在命令行临时定义的别名只存在于当前 Shell 会话。持久定义通常放入相应的交互启动文件，但要先确认发行版与 Shell 的启动文件顺序。

最容易埋坑的别名是给高风险命令暗中加默认选项。例如让 rm、cp 或 mv 始终带某个交互/强制选项，会让你对标准行为形成错误肌肉记忆。一旦到了没有该别名的会话或自动化环境，同一行输入就会变成另一种行为。

需要参数、分支或改变 Shell 状态时用函数

当快捷命令需要安全地处理参数时，函数比别名清楚得多：

mkcd () {
  if (( $# != 1 )); then
    printf 'usage: mkcd DIRECTORY\n' >&2
    return 2
  fi
 
  mkdir -p -- "$1" && cd -- "$1"
}

这里有几个别名很难自然表达的能力：

• "$1" 明确使用第一个位置参数，引号保留含空格路径的单一参数边界。
• -- 让支持该约定的程序停止解析选项，减少以 - 开头名称被当成选项的风险。
• return 2 使用明确状态表达参数不符合接口。没有显式 return 时，函数通常使用最后一条实际命令的退出状态。
• cd 在当前 Shell 上下文执行，所以函数返回后仍保留新工作目录。

函数内的临时变量应使用 local，避免无意覆盖外层同名变量。如果逻辑越来越长，还需要跨 Shell 执行、独立测试、版本化发布或明确依赖，就应迁移到脚本或正式程序，不要把整个工具塞进 .bashrc 函数里。

判断使用哪一种形式，可以记一条很实用的线：固定文本缩写用别名；需要参数与 Shell 状态用函数；需要跨环境、可测试与可发布时用脚本或程序。

帮助入口要与命令类型匹配

面对陌生命令，不需要把所有帮助工具按顺序都试一遍。第一步仍然是确认来源：

type -a name
command -v name

知道它是 Bash 内建、外部程序、别名还是函数之后，帮助入口自然就分流了。

Bash 内建用 help，程序自述用它自己的选项

查 Bash 内建命令，先问 Bash：

help cd
help type
help command
help hash

help cd 会说明 cd 的语法、选项和与 HOME、OLDPWD 的关系。这比在 PATH 里寻找一个不存在的独立 cd 更直接。

许多 GNU 外部程序提供 --help：

/bin/ls --help
mkdir --help

它们适合快速查用法和选项。但 --help 不是 Shell 强制所有程序实现的语法。有的程序用 -h，有的要求 --help 是唯一参数，有的工具根本没有这个选项。当 which --version 返回 Illegal option -- 时，问题不是系统损坏，而是这个 which 实现不接受 GNU 风格长选项。

man 是手册阅读器，章节号用来解消歧义

man 页偏向参考，通常不会按“初学者第一步做什么”的节奏展开。进入页面后，可以优先定位 SYNOPSIS、DESCRIPTION、OPTIONS、EXIT STATUS、ENVIRONMENT、FILES、EXAMPLES 和 SEE ALSO。

手册系统用章节号区分不同类型的主题：

所以，下面两条命令问的不是同一件事：

man 1 passwd    # passwd 用户命令
man 5 passwd    # passwd 账号文件的格式

只知道功能关键词，不知道页面名时，可以搜索手册摘要：

apropos 'list directory'
man -k 'list directory'

只想看某个名称的一行摘要，可使用：

whatis ls
man -f ls

apropos 与 whatis 通常依赖 whatis 索引数据库。“nothing appropriate”不能直接推导为“这个功能不存在”；还可能是页面没有安装、索引未更新、关键词不在摘要或章节范围过窄。

图：章节号先区分主题类型，页内标题再帮你快速定位接口、状态与环境依赖。

info 和官方在线文档补充更长的说明

GNU 项目常用 Texinfo 组织长文档，Info 阅读器以节点、菜单和索引在这些文档中导航：

info coreutils
info ls
info coreutils 'ls invocation'

info ls 不一定寻找一个独立 ls.info，它可以通过顶层目录项跳到 Coreutils 手册内的 ls 节点。这种结构适合一组工具共用概念和索引。

阅读器与文档数据是两件事。一次精简 Debian 环境中，安装 man-db、manpages 和 info、运行 mandb 后，man 1 ls 仍然提示没有页面，info ls 也提示顶层目录无 ls 项。原因是该精简镜像没有提供对应的 Coreutils 手册/Info 数据，不是 ls 没有接口说明。

当本地文档缺失时，下一步是记录程序版本和发行版信息，再访问对应项目的官方文档。如果问题涉及可移植性，还要对照 POSIX 或其他目标标准。

图：最快的帮助路径不是固定命令顺序，而是先把问题送给正确的接口。

从错误消息反推失败发生在哪一层

命令失败时，最糟糕的处理方式是不看输出，只把原命令重新敲几遍。更高效的方法是先把诊断拆开，判断故障尚未离开 Shell，还是已经进入目标程序。

用“报告者、对象、原因、状态”四格读错

先看两条很像的消息：

bash: definitely_missing_ch05: command not found
ls: cannot access '/tmp/welearn-ch05/missing': No such file or directory

第一条的报告者是 bash。它在命令查找阶段没有找到要启动的目标，所以目标程序根本没有运行。排查重点是拼写、当前 Shell 的函数/内建层、PATH、缓存和软件包状态。

第二条的报告者是 ls。这说明 Shell 已经成功启动 ls，失败对象是 /tmp/welearn-ch05/missing，原因是路径无法解析到存在对象。排查重点应转向参数、引号、工作目录和路径分量。

No such file or directory 还有一个容易忽略的变体：脚本文件明明存在，直接执行却报“不存在”。这时缺失的可能是 shebang 中的解释器，或者文件含有不可见的回车字符，让内核尝试了一个错误解释器路径。

图：先判断谁在报错，就能把排查范围缩小到 Shell 查找、执行过渡或程序内部。

退出状态与第一条错误一起读

屏幕文字和退出状态是两个不同信号。命令可以不输出文字但返回失败，也可以输出诊断后仍用自己定义的状态表达结果。因此在目标命令后立即保存 $?：

some_command
status=$?
printf 'status=%s\n' "$status"

不要先执行其他命令再读 $?，因为任何后续命令都会覆盖它。在管道中，Bash 默认以最后一个管道元素的状态作为整体状态；需要追踪左侧失败时，要理解 PIPESTATUS 或明确评估 set -o pipefail 对脚本控制流的影响。

一次失败引发多条后续诊断时，优先处理最早的根因。例如配置文件未找到后，程序可能继续报告连接、认证和输出依赖都失败。如果不先修复第一条，后面的消息只会让人误以为有很多独立问题。

将正常输出和诊断分开也有帮助：

some_command >result.log 2>error.log
status=$?

这不是为了隐藏错误，而是让 stderr 不被大量正常数据淹没，并且让调查过程可重现。

从错误反推失败层级时，可以快速记住这组对照：bash: NAME: command not found 优先查名称解析；Permission denied 优先查权限、挂载和文件格式；PROGRAM: ... unknown option 表示程序已经启动，参数接口不匹配；PROGRAM: OBJECT: No such file or directory 则优先检查程序收到的对象路径。

用一次隔离实验把查找、缓存和状态串起来

下面的练习在一次性 Debian 容器中创建两个同名 probe，让前置路径先被缓存，再移除它，最后比较 hash -r 前后的结果。它还创建一个没有执行位的 blocked，用于区分 126 与 127。

docker run --rm \
  --name welearn-linux-ch05-lab \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --network none \
  --read-only \
  --tmpfs /tmp:rw,nosuid,nodev,size=16m \
  debian:bookworm-slim \
  bash --noprofile --norc -lc '
set -u
work=/tmp/welearn-ch05
mkdir -p "$work/a" "$work/b"
trap "rm -rf \"$work\"" EXIT
 
ln -s /bin/echo "$work/a/probe"

这个练习每一步都有明确目的：

容器使用只读根文件系统、无网络、无 capability 和只存在于内存的 /tmp。trap 在 Shell 退出时删除实验目录，--rm 再删除退出容器。这样的设计不是为了让命令看起来复杂，而是让实验边界、失败原因和清理结果都能被复核。

遇到陌生命令时的完整排查清单

学完这些工具，最有价值的不是记住每个选项，而是形成一条不跳步的调查链。下次遇到“这个命令怎么和预期不一样”，可以按下面的顺序做。

这条链的核心是把推测变成可验证事实：先确认名称在当前 Shell 中的身份，再确认外部路径与执行条件，最后用对应文档和退出状态解释行为。做到这一点，命令行就不再是一串需要猜的黑箱字符。

hash -r 后再运行，命中 b，证明修复原因是重新执行 PATH 搜索，而不是重试本身带来了随机好转。

如果命中外部文件，打印 PATH 并检查同名候选的顺序。对含 / 的输入则直接检查该路径，不要继续在 PATH 上浪费时间。