写脚本、敲命令的时候，冒出一个没见过的命令，或者记得某个命令但想不起某个参数怎么写——这种场景几乎每天都会遇到。很多人第一反应是打开浏览器搜索，但终端里其实自带一整套比搜索引擎更快、更准的查法：man、apropos、--help，选对工具往往比记住参数本身更重要。

这是终端效率小系列的第一篇，后续还会写 vim 基本操作、Emacs 风格快捷键与进阶技巧。

打开一个命令的 man 页面，看到的是什么

man 后面跟命令名，比如 man ls，打开的页面几乎总是这几个固定部分组成的，认清这个结构，比死记某一个命令的参数更有用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
NAME
     一句话描述这个命令是干什么的，最快判断"是不是我要找的东西"就看这里

SYNOPSIS
     用法概要，一行或几行，用方括号/尖括号/省略号表示参数是否必填、能不能重复
     （这套符号约定和 --help 输出的用法概要是同一套规则，后文详细展开）

DESCRIPTION
     详细说明，参数多的命令这部分会很长，是真正讲清楚"每个参数具体做什么"的地方

OPTIONS
     参数列表，部分命令会把这部分和 DESCRIPTION 合并，不单独分节

EXAMPLES
     实战示例，不是所有命令都有这部分，有的话是最值得先看的地方

SEE ALSO
     相关命令，遇到一个命令做不到想要的效果，这里经常能带出更合适的那个

AUTHOR
     作者信息，日常查阅基本用不上

拿到一个陌生命令，不用从头到尾通读，思路应该是：先看 NAME 确认找对了地方，直接跳到 EXAMPLES（如果有）抄一个改改能用最好，改不出想要的效果再回头看 OPTIONS/DESCRIPTION 找具体参数。

为什么会查到同名但不是你想要的条目

有时候 man 打开的页面内容明显不对——比如查 printf 却看到一堆看不懂的返回值类型和参数说明。这不是找错了命令，是 man 手册本身按内容类型分成好几个”层”（section），同一个名字在不同层里可能是完全不同的东西：

章节 内容
1 用户可以直接执行的命令或 shell 命令
2 系统调用——内核提供的功能
3 库函数——程序库里的函数（大部分 libc 函数在这里）
4 特殊文件，通常是 /dev 下的设备文件
5 文件格式和约定，比如配置文件的写法
6 游戏
7 杂项——协议、字符集标准、文件系统布局这类概览性内容
8 系统管理命令，通常只有 root 能执行
9 内核例程，非标准章节，不是所有系统都有

printf 在 man 手册里至少有两个条目：

1
2
3
4
5
6
7
8
9
10
man 1 printf
#     章节 1：shell/coreutils 提供的 printf 命令，格式化输出文本用

man 3 printf
#     章节 3：C 标准库里的 printf() 函数，写 C 代码时才会用到

man printf
#     不指定章节，man 按顺序查找，通常先找到章节 1 的版本
#     但这个"通常"不是保证——取决于系统配置，遇到内容明显不对时,
#     加上章节号重新查是最快的解法

printf 只是最经典的例子，很多名字在用户命令和库函数/系统调用里都同时存在。查手册时如果内容感觉不对（比如冒出一堆看不懂的 C 类型），第一反应应该是”这是不是查到别的章节去了”，加上章节号重新查。

man 内部导航：其实你在用 less

man 本身不负责分页显示，它把内容交给一个分页器（pager）处理，默认通常是 less。这意味着 less 的快捷键在 man 里全部适用，这是查手册最实用的一套技能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
man tar
#     打开后是 less 在分页显示内容，以下操作都在这个界面里进行

# 翻页
空格 或 f    #     向下翻一页
b            #     向上翻一页

# 搜索
/关键词       #     向下搜索关键词，比如 /-f 找 -f 参数的说明
?关键词       #     向上搜索关键词
n            #     跳到下一个匹配
N            #     跳到上一个匹配（大写，方向和 n 相反）

# 退出
q            #     退出 man，回到命令行

一个几百行的手册页，靠肉眼从头翻到尾找一个参数是最低效的做法——/参数名 直接跳过去，才是正确用法。

忘了具体命令名，只记得想干什么，怎么搜

前面几节都假设你已经知道命令名，只是想搞懂它怎么用。但更常见的场景是：只知道自己想干什么（比如”压缩文件”），完全不确定该用哪个命令。这时候 apropos 或 man -k 才是该用的工具——这两个是同一件事：搜索所有手册页的一句话描述（也就是前面提到的 NAME 那一行）里包含指定关键词的条目：

1
2
3
4
5
6
7
apropos compress
#     搜索所有命令里，一句话描述包含 "compress" 的条目
#     结果会列出 gzip、tar、zip 等等一堆候选，帮你先找到该用哪个命令

man -k compress
#     和上面等价——man -k 内置在 man 命令里，apropos 是独立命令，
#     两者功能相同，apropos 在个别精简系统上可能需要单独装，man -k 只要装了 man 就有

结合前面讲的定位技巧，实战流程通常是这样：apropos 先找到候选命令名 → man 打开确认 NAME 对不对 → /参数名 跳到具体参数说明。

1
2
3
4
man tar
# 打开后输入：
/-f
# 直接跳到 -f 参数的说明段落，不用从头翻

--help：比 man 快，但要先看懂它的格式

man 详细但长，很多时候你只是想快速确认”这个命令到底有没有我要的参数”，这时候 --help 比翻 man 快得多：

1
2
tar --help
#     大多数命令都支持这个参数，输出比 man 手册短得多，只列参数不讲原理

--help 的输出通常分两部分：开头一行 用法概要（usage synopsis），后面跟着参数列表。用法概要这一行的符号是有约定含义的，看懂它比记住某个具体命令的用法更重要——这套约定跟前面 man 页面 SYNOPSIS 里的符号是同一套规则：

1
2
3
4
Usage: tar [OPTION...] [FILE]...
#      OPTION...：方括号 [ ] 表示可选，... 表示可以出现多次（可以传多个 OPTION）
#      FILE...：同样可选、可重复，表示可以传多个文件
#      没有方括号、直接写出来的部分（比如命令名本身）是必需的

常见约定：方括号 [ ] 包起来的是可选项；尖括号 < > 或者不带括号直接写的词是必填项；省略号 ... 表示前面那一项可以重复出现；竖线 | 表示几选一。这套约定不是 tar 专属的，几乎所有遵循 GNU/POSIX 惯例的命令都这么写，学会看一次，后面每个命令的用法说明都能看懂。

参数列表部分，每个参数通常是”短选项, 长选项 说明文字”这样的格式排开。输出长的话，直接用 --help 配合搜索工具：

1
2
3
4
5
6
tar --help | grep -A1 "exclude"
#     grep 从 --help 的输出里过滤出包含 "exclude" 的行，-A1 多带一行看清楚说明
#     比整段输出里肉眼找快得多，尤其是参数很多的命令（比如 tar、find）

curl --help | less
#     curl 的 --help 输出本身就很长，直接接 less 分页，用前面讲过的 / 搜索快捷键定位

--help 和 man 不是二选一：先用 --help 快速扫一眼有没有你要的参数，确认存在了但不确定具体行为，再去 man 里查那一条的详细说明。

man 之外的其他辅助手段

  • tldr：直接给实战例子，不讲原理只给”抄了就能用”的命令，想直接抄一条命令用时最合适
  • info：GNU 项目常用的另一套文档系统，比 man 更结构化（支持章节跳转、超链接式导航），但普及度不如 man，主要是 GNU 核心工具用得多，比如 coreutils 这个包

遇到不认识的命令，apropos 先定位候选命令；确定命令了，--help 快速确认有没有要的参数；想深入理解某个参数为什么这么设计，才去查 man 的 DESCRIPTION；懒得看文档直接要例子，tldr。几种手段配合用，不是非此即彼。

终端效率小系列：下一篇

下一篇讲 vim 基本操作——毕竟查完命令用法，回头改配置文件、写代码，还是得会用编辑器。