第 14 章 命令行与 Shell 速查

面试不考参数背诵，而是给你一个故障现场让你现场拼管道；本章按场景组织，重点在管道的中间结果与坑。

学习目标

读完本章，你应当能够：

1. 面对"从这份日志里求出 X"的现场题，先说出管道每一段的中间结果形态，再落笔写命令；
2. 辨析 grep -c、uniq -c、wc -l 三者统计口径的差异，判断一条命令到底在数"行"还是数"次"；
3. 写出 find 与 xargs 的安全组合，说明 -exec \; 与 -exec + 的进程数差异、-print0 为什么必须配 -0；
4. 解释 cmd > f 2>&1 与 cmd 2>&1 > f 结果不同的原因，并说明 set -euo pipefail 三项各治什么病、-e 在哪些语法位置静默失效；
5. 从一份 Nginx 访问日志出发，完整推导 TOP10 IP 与每 IP 的 TOP1 URL（含内存受限时的替代写法）。

前置知识检查

14.1 命令行面试的真实考法

“说出 grep 的十个参数"这类题已经很少见，因为它可以用手册回答，无法区分候选人。主流形态是给一个现场，让你现场拼命令，考的是：口径是否清楚（问"有多少次访问失败"要先确认失败按状态码 ≥ 400 还是按 5xx，按行数还是按请求数）；能不能说出中间结果（面试官常在你写到一半时打断"这一步之后每行长什么样”，答不上来说明是背过的命令而非推出来的）；知不知道边界（空输入、超大文件、文件名带空格、管道前段失败而后段成功）；能不能收窄（先给能跑的粗版本，再按"内存受限、不许写临时文件、只统计今天"等新约束逐步改）。

14.2 文本三剑客的高频用法

14.2.1 grep：过滤与计数，以及 -c 的口径

grep 是逐行匹配器：按行读入，行内只要有一处匹配，该行即命中。这个模型直接决定了 -c 的行为——它数的是命中行数而非匹配次数：一行里出现 3 次 ERROR，-c 只记 1。

1
2
3
4

# 同一份文件，三种口径给出三个数，选错口径答案就是错的
grep -c 'ERROR' app.log          # 命中行数：一行里有 10 个 ERROR 也只加 1
grep -o 'ERROR' app.log | wc -l  # 匹配次数：-o 把每个匹配单独打成一行再数行
grep -v -c 'ERROR' app.log       # -v 先反选，这里数的是"不含 ERROR 的行数"

-o（only-matching）是唯一能把"次数"变回"行"的手段；反过来说，任何"数次数"的需求都要先经过 -o 或 awk 的关联数组。

grep 的退出码是脚本里的坑：0 命中、1 未命中、2 出错。所以 grep ... || true 与 if grep -q ... 是两套语义——前者把"找不到"当成功，后者能区分"找不到"与"文件读不了"。

14.2.2 sed：流式编辑器，重点是 -i 与地址范围

sed 的模型是逐行读入、按地址选择、执行命令、输出，默认打到标准输出（所以 sed 's/a/b/' f 不改文件）。它最适合逐行变换：替换、按行号或正则区间增删、流式清洗。

1
2
3
4
5

sed -n '10,20p' file                  # -n 关掉默认输出，p 只打印选中行，等价于 head/tail 组合
sed -n '/BEGIN/,/END/p' file          # 正则区间：从匹配 BEGIN 的行到其后第一个匹配 END 的行
sed -i.bak 's/old/new/g' f            # GNU：-i 可紧跟备份后缀，先生成 f.bak 再原地改 f
sed -i '' 's/old/new/g' f             # BSD/macOS：备份后缀是独立参数，空串表示不备份
sed -E 's/([0-9]+)ms/\1 毫秒/' file   # -E 打开 ERE，反向引用写作 \1、\2；& 代表整个匹配

-i 的 GNU 与 BSD 差异是参数解析差异：GNU 把后缀写成紧邻 -i 的可选参数，BSD 把它当下一个独立参数。于是 sed -i 's/a/b/' f 在 macOS 上把 s/a/b/ 误当备份后缀、再因缺少脚本报错，跨平台写法是 sed -i.bak -e 's/a/b/' f 或用 perl -i -pe。

-i 是"写新文件再改名"，不是"就地改写字节"，因此 inode 会变（硬链接断开、正在 tail -f 的读者可能跟丢），且改写期间磁盘空间短暂翻倍。-n 与 p 是绑定出现的一对：sed '5p' f 会把第 5 行打印两次。另外地址范围是粘性的：/BEGIN/,/END/p 命中 BEGIN 后一直选到下一个 END，中间再出现 BEGIN 也不会重开区间。

14.2.3 awk：唯一能"跨行聚合"的现场工具

awk 的模型是记录-字段：默认按换行切记录、按空白切字段，对每条记录执行 {...}；BEGIN 在读取前执行一次，END 在读完所有输入后执行一次。“读完才执行 END“正是它能做聚合的根本原因——不像 sed 那样输出完一行就丢掉状态。

1
2
3
4
5

awk -F'|' '{print $2}' f            # -F 指定分隔符，多字符或正则均可（-F'[|,]'）
awk '{print $(NF-1), $NF}' f        # NF 是本行字段数，$NF 是最后一列；$0 是整条记录
awk 'NR>1 {print}' f                # NR 是全局已读记录数，用来跳表头
awk '{s+=$3} END{print s, s/NR}' f  # 按列求和与平均值：累加在字段上，除法放 END
awk '{a[$1]++} END{for(k in a) print a[k], k}' f   # 关联数组是哈希表，不是线性表

关联数组是 awk 与 grep/sed 的分水岭：a[$1]++ 的语义是"用字段值当键做一次哈希查找并自增”，于是它在输入只扫一遍的前提下完成去重、分组、计数、求和；sort 系工具则必须先排好序。这个差别在内存上会反转：关联数组把所有不同的键驻留在内存里，键多则内存暴涨——这正是 14.8 节的内存判据。

14.3 进程与端口排查

14.3.1 ss 取代 netstat 的真实原因

ss 与 netstat 的差别不是参数风格，而是数据来源。netstat 从 /proc/net/tcp 之类的文本文件读全表并自行解析，还要把每个 socket 的 inode 去 /proc/<pid>/fd 反查进程名——这一步是 O(套接字 × 进程 × fd) 的扫描。ss 走 NETLINK_SOCK_DIAG（man 7 sock_diag）直接向内核请求套接字诊断信息，由内核侧完成过滤。于是在套接字到十万量级时，netstat 需要数秒到数十秒并明显吃 CPU，而 ss 仍在百毫秒以内。

1
2
3
4
5

ss -lntp                  # -l 只看监听，-n 不做服务名与 DNS 解析，-t TCP，-p 显示进程
ss -tn state established  # 显式按状态过滤：内核侧只返回该状态的套接字
ss -s                     # 汇总视图：各协议的套接字总数与状态分布
lsof -i:8080              # 涉及 8080 的所有 fd；本质是遍历 /proc/*/fd 反查 socket inode
fuser -n tcp 8080         # 只输出占用该端口的 PID，适合直接喂给 kill

-p 需要权限才看得到别人的进程：它依赖 /proc/<pid>/fd 的可读性，无权限时该套接字的进程信息为空。ss -s 的价值是一眼看出总量结构——estab/closed/orphaned/timewait 的分布，是判断"连接泄漏还是端口耗尽"的第一手材料；若 timewait 数量级远超 estab，方向应转向谁在频繁短连接（见第 16 章 16.4 节）。

lsof -i 慢的原因值得知道：内核没有"按端口查进程"的接口，只能遍历每个进程的 fd 目录。这也解释了容器场景下的经典困惑——容器里 ss -lntp 常显示 pid=1，而该 PID 在宿主机上并不对应同一个进程；因为进程反查依赖 /proc，而 /proc 只含本 PID 命名空间的进程。跨命名空间排查要么进容器，要么用 nsenter -t <pid> -n。

14.3.2 ps 的两种方言与进程信号

ps -ef 是 System V 风格，ps aux 是 BSD 风格，两者都能列出全部进程，但列名与语义不同：-ef 给 UID PID PPID C STIME TTY TIME CMD，aux 给 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND。关键差别是 %CPU/%MEM/RSS 只有 BSD 方言直接给，PPID 只有 System V 方言直接给（BSD 侧要 ps -o ppid）。要锁死列序与列名，用 -o 显式指定更可靠：

1
2
3
4

ps -eo pid,ppid,stat,rss,etime,cmd --sort=-rss | head -20   # 比 top 更适合写进脚本
pgrep -f 'java.*-Xmx'   # 按完整命令行匹配（-f）取 PID，可做存在性判断
pkill -f 'java.*-Xmx'   # 语义是发默认信号 SIGTERM，不是强制杀
kill -0 "$pid"          # 发"空信号"：只做权限与存在性检查，不投递任何信号

kill -0 的判定要精确：返回成功说明进程存在且当前用户有权给它发信号；返回 EPERM 说明进程存在但权限不足；只有 ESRCH 才说明不存在。所以失败不等于"进程没了"——这是脚本里最常见的误判。它常被用作"等待进程退出"的轮询条件，但僵尸进程仍然"存在"，kill -0 对它成功（回收语义见第 4 章 4.4 节）。

14.4 日志分析：排序、去重与计数

14.4.1 sort 的现场选项

1
2
3
4
5
6
7

sort -c file              # 只检查是否已排序（可校验上游是否真按时间写过）
sort -n -k2,2 -k1,1r f    # -n 数值序；-k2,2 限定只比较第 2 字段，避免把后文也当键
sort -u -k1,1 f           # 按第 1 字段去重，保留每组中排在最前的整行
sort -s -k1,1 f           # -s 稳定排序：键相等时保持原输入顺序
LC_ALL=C sort big.log     # 强制 C 区域按字节比较，通常比 UTF-8 区域快一个量级
awk '{print $1}' access.log | uniq -c                          # 错误：同一 IP 不相邻就各占一行，计数全是 1
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10   # 正确：先聚拢再压缩再排序

三个必须记住的细节：-k 要写全 起点,终点，只写 -k2 会让键一直延续到行尾（等于"先比第 2 字段，再比后面所有字段"），这是"排序看起来没生效"的头号原因；-k2,2n 里的 n 修饰的是这个键，位置不能乱；LC_ALL=C 不仅更快，还会改变比较结果（区域感知比较会忽略标点权重），改口径要和业务确认。

14.4.2 uniq -c 为什么必须与 sort 连用

uniq 只比较相邻行：它不查表、不占内存，代价就是非相邻的重复行看不见（对比 14.4.1 代码块的最后两行）。

这不是缺陷而是设计：正因为只看相邻，uniq 才能用常量内存处理任意大小的输入，而"聚拢相同项"的责任交给 sort——两步分工换来整体的可扩展性。sort 自身是外部归并排序：内存放不下就落临时文件再归并，所以 sort | uniq 的瓶颈通常落在磁盘 I/O 而非内存。若看到 sort: cannot create temporary file，那是 TMPDIR 空间不足，不是内存不足。

14.4.3 内存受限时：sort -u 还是 awk 关联数组

正确答案取决于"不同的键有多少"，而不是"文件有多大"：

判断方法很实际：先估基数。awk '{print $7}' access.log | sort -u | wc -l 本身就是"用磁盘换内存"的探针——跑得动说明基数可控，跑不动就说明关联数组方案不能用。wc -l 的口径也要交代清楚：它数的是换行符个数，末行没有换行符会少算一行，而 awk 'END{print NR}' 数的是记录数，做行数校验时两者不一致是正常现象。

cut 与 awk 的分工按"输入规整程度"切：cut 用单字符分隔符或固定列位置、不处理连续空白，但轻量且不写脚本；日志用空格对齐就用 awk '{print $3}'，逗号分隔就用 cut -d, -f2。tr 与 sed 的分工是字符级还是模式级：tr 只做单字符到单字符的替换与删除（tr -d '\r'、tr 'A-Z' 'a-z'），不支持正则与多字符替换；需要按模式替换就用 sed。tee 的价值是在管道中间留一份现场：cmd | tee raw.txt | awk ... 把上游原始输出落盘，事后换下游写法重算，不必重跑上游（对只能跑一次的抓包、压测尤其关键）。

14.5 find 与 xargs 的组合与陷阱

14.5.1 -exec \; 与 -exec + 的进程数差异

find -exec 的两种终止符决定命令被调用几次，这不是写法差异而是 fork/exec 次数的差异——每次调用都是一次量级约 100 μs ~ 1 ms 的进程创建（见第 4 章 4.1 节）。

1
2

find . -type f -name '*.log' -exec gzip {} \;   # 每个文件一次：10000 个文件 = 10000 次 fork+exec
find . -type f -name '*.log' -exec gzip {} +    # 每批一次（受 ARG_MAX 约 2 MB 限制）

用 + 要同时满足三条：被调用命令必须接受多个文件名参数（gzip a b c 可以，mv、basename 不行）；{} 只能出现在命令末尾；需要管道或重定向的复合命令只能退回 \;。

14.5.2 文件名含空格：-print0 与 xargs -0

find 默认用换行分隔输出，而 xargs 默认按空白与引号分词。两条规则叠加的后果是：文件名里有空格就被拆成两个参数，有引号就被当成引用语法，有换行则直接错乱。

1
2

find . -type f -name '*.tmp' -print0 | xargs -0 rm -f   # -print0 用 NUL 分隔，-0 按 NUL 切分
find . -type f -name '*.tmp' -exec rm -f {} +           # 更省事：完全绕开 xargs 的分词

NUL 是唯一不会出现在文件名里的字节，所以它比"转义空格"可靠——转义方案在文件名同时含单引号与空格时仍会崩。另一个细节：GNU xargs 在输入为空时仍会执行一次命令，-r 可避免；xargs -P N 可并行，但输出会交错，聚合类任务不要直接用它。

14.5.3 时间与大小条件，以及 -delete 的风险

-mtime/-size 的比较语义都是按单位向下取整后再比较：-mtime 0 指"不满 1 个 24 小时周期"（不是"今天"），-size 1M 指"向上取整到 1 MB 单位后等于 1"，即实际大小落在 (0, 1 MB]；要表达严格大于必须用 +：-size +100M 是"大于 100 MB"。

1
2
3

find /data -xdev -type f -name '*.log' -mtime +7 -size +10M -print   # -xdev 不跨文件系统
find /data -type f -newer /tmp/stamp -print                          # 比参考文件更新的文件
find /data -type f -name '*.tmp' -print0 | xargs -0 rm -f            # 危险操作的稳妥形态

-delete 的风险集中在三点：它是不可回滚且不二次确认的删除；-delete 隐含深度优先遍历（先处理子项），因此会连空目录一并删掉——路径写错一级就从"一个目录"变成"整棵子树"，所以必须用 -type f 或明确的 -name 收窄；遍历同时修改目录树还会让某些目录项被跳过或触发告警。稳妥模板是：先把 -delete 换成 -print 跑一遍，确认输出集合，再执行删除。

14.6 管道与重定向

14.6.1 > 与 >>，以及 2>&1 的顺序陷阱

Shell 处理重定向的规则是：从左到右依次求值，N>&M 的语义是"把 fd N 复制为 fd M 此刻指向的目标"，不是"让 fd N 永远跟着 fd M 走"。这一条直接推出经典陷阱的两个结果：

1
2
3
4
5
6
7
8
9

cmd > f 2>&1 ：先让 fd1 指向 f，再让 fd2 复制 fd1 ⟹ stdout 与 stderr 都进 f（顺序正确）
cmd 2>&1 > f ：先让 fd2 复制"当时的 fd1"（终端），再让 fd1 指向 f
               ⟹ stderr 留在终端，只有 stdout 进 f（这就是"日志里没有报错"的原因）

求值过程（N>&M 是复制 fd 当前目标的快照，不是持续绑定）：
初始：fd1 ──▶ 终端        fd2 ──▶ 终端
cmd 2>&1 > f  第 1 步 2>&1 → fd2 ──▶ 终端（fd1 此刻仍是终端）；第 2 步 > f → fd1 ──▶ f
              结果 fd1 ──▶ f、fd2 ──▶ 终端 ⟹ 报错仍在屏幕上，日志文件里一行错误都没有
cmd > f 2>&1  第 1 步 > f → fd1 ──▶ f；第 2 步 2>&1 → fd2 ──▶ f ⟹ 两个流都进文件

Python 的 -u、Java 的 stdout 缓冲会给"为什么日志顺序不对"再叠一层：stdout 默认行缓冲或块缓冲，stderr 无缓冲，所以即便两个 fd 指向同一文件，写入顺序也不保证与代码执行顺序一致。要按时间对齐，必须在应用侧统一走同一个 logger，或在 Shell 侧把 stderr 也并进同一个已缓冲的 fd。

14.6.2 进程替换与后台管道

进程替换 <(cmd) 让命令的输出表现为一个可读的文件路径（内核侧是 /dev/fd/N 或命名管道），从而把它塞进只接受文件名的位置，例如 diff <(sort a.txt) <(sort b.txt) 就不必生成两个临时文件。它更重要的用法是保留循环状态：tail -f app.log | while read ... 会把循环体放进子 shell，循环里设置的变量在结束后丢失；换成 while read -r line; do ...; done < <(tail -f app.log) 就把读取重定向到当前 shell——这正是"循环里累加的计数器最后总是 0"的根因。管道还有一处：cmd | while read 的退出码是 while 的（要 pipefail 才能暴露上游失败），且各段同时并发执行——上游先启动、下游边收边处理。cmd & 把命令放后台，$! 取它的 PID，wait 回收。

14.7 Shell 脚本的健壮性

14.7.1 set -euo pipefail 三项各治什么病

1
2

#!/usr/bin/env bash
set -euo pipefail   # -e 出错即退；-u 引用未定义变量即退；-o pipefail 管道任一环节失败整条管道就非零

-e 的失效场景必须逐条记住，否则"加了 -e 就安全"是错觉：命令处在被测试的位置时（if cmd; then、while cmd; do、cmd || true、! cmd）失败不会触发退出，因为它的状态正是要被读取的；没有 pipefail 时 cmd1 | cmd2 的退出码来自 cmd2，cmd1 失败会被完全吞掉；带命令替换的赋值 local x=$(cmd) 的退出码是 local 的（永远成功），命令替换失败被掩盖，这是除了 pipefail 之外还要拆分赋值的常见理由；函数被调用在条件位置时，函数返回值就是其最后一条命令的返回值，函数内部所有命令都落入"被测试"上下文。

IFS 与 -u 常一起出现：默认 IFS 含空格、制表、换行，for x in $var 依赖它分词；读文件要 while IFS= read -r line——IFS= 防止行首尾空白被吞，-r 防止反斜杠被当成转义。

14.7.2 五个特殊变量与 $@ / $* 的差异

未加引号的 $@ 与 "$@" 差别很大：前者会再做一次分词与通配符展开，参数里带空格或 * 就会被破坏——这就是"脚本转发参数后行为变了"的根因。

14.7.3 trap、[ ] 与 [[ ]]

trap cleanup EXIT INT TERM 把清理挂到正常退出、错误退出与两个常见信号上；trap '' INT 表示忽略该信号（信号被吞掉、进程不退出），trap - INT 恢复默认处置。两个坑：EXIT 上的清理函数在退出码已被决定之后才执行，因此它读得到 $? 能做条件清理；trap 处理函数执行期间同一信号默认被屏蔽（不重入）。另外 SIGKILL/SIGSTOP 无法被捕获，kill -9 场景下 trap 不会执行（见第 10 章 10.2 节）。

[[ ]] 是 Bash 的关键字（语法级），[ ] 是 test 内建命令（命令级）。这个身份差异推导出全部行为差异：

现场结论：脚本头部写 #!/usr/bin/env bash 就用 [[ ]]，理由是引号遗漏导致的 bug 远比可移植性更重要；只有当脚本必须跑在 sh/dash（精简基础镜像、部分 RUN 指令的默认 shell）上时才退回 [ ] 并逐一加引号。

14.8 完整推导题：一条命令求出 TOP10 IP 与每 IP 的 TOP1 URL

题面：给定 Nginx 默认 combined 格式的 access.log，求出访问量 TOP10 的客户端 IP；并进一步求出每个 IP 访问量最高的那个 URL。内存有限，说明为什么你的写法能在有限内存下完成。

1
2
3
4
5

combined 格式：$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
一行的字段切分（$7 带前导引号，这是本题最易错的地方）：
203.0.113.7 - - [10/Oct/2024:13:55:36 +0800] "GET /api/v1/orders?id=42 HTTP/1.1" 200 512 "-" "curl/8.4.0"
│             │                            │                                   │     │
$1            $4                           $7                                  $9    $10

关键判据：$1 是 IP，$7 是带查询串的完整请求目标，它由双引号包着但仍能被空白切出来（"GET、/api/v1/orders?id=42、HTTP/1.1" 是三个字段，我们要的是中间那个）。正确切法是取 $7 后 sub(/^"/,"") 去掉前导引号；想按 URL 路径聚合而非完整 URL，再剥掉 ? 之后的内容。

第一步：TOP10 IP。 计数类需求走 sort 与 uniq -c 的经典组合：

1
2
3
4
5
6
7
8
9

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10
# 中间结果逐步看：
#   awk '{print $1}'   ⟹ 每行一个 IP，可能重复
#   sort               ⟹ 相同 IP 聚成连续块
#   uniq -c            ⟹ 压缩成 "计数 IP"（计数列到这里才出现）
#   sort -nr           ⟹ 按计数从大到小（-n 数值序，-r 逆序）
#   head -10           ⟹ 只取前 10 行，并提前终止上游
grep -v -e '/healthz' -e '/metrics' access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10
# 上一行排掉探活噪声，否则 TOP10 会被探活打乱

第二步：每个 IP 的 TOP1 URL。 这里必须用关联数组，因为 sort | uniq -c 只能给出 (IP, URL) 二元组的频次，无法在组内取最大值。做法是"先按二元组计数，再在 END 里按 IP 分组取最大"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

awk '
{
    ip = $1; url = $7
    sub(/^"/, "", url)       # 只去掉 $7 的前导引号；要完整 URL 就保留查询串
    sub(/\?.*$/, "", url)    # 只要路径就剥掉查询串；要完整 URL 则删掉这一行
    cnt[ip SUBSEP url]++     # SUBSEP 由 awk 注入，避免 "1.2"+"3" 与 "1"+"2.3" 撞键
}
END {
    for (k in cnt) { split(k, p, SUBSEP); if (cnt[k] > best[p[1]]) { best[p[1]] = cnt[k]; top[p[1]] = p[2] } }
    for (ip in best) printf "%8d  %-15s  %s\n", best[ip], ip, top[ip]   # 输出：计数、IP、TOP1 URL
}' access.log | sort -nr | head -10
#      812  203.0.113.7      /api/v1/orders
#      407  198.51.100.23    /api/v1/users

内存占用是 O(不同的 (IP, URL) 二元组数) 加 O(不同 IP 数)，与总行数无关——日志涨到 100 GB，只要二元组基数稳定在几十万，内存就是几十 MB 量级；但若 URL 带高基数参数（时间戳、UUID），二元组基数逼近行数，必须先规范化 URL 或只统计路径。

内存更紧时用两次外部排序把状态换成磁盘（sort 内存由 -S 控制、超出落 TMPDIR）：

1
2
3

awk '{u=$7; sub(/^"/,"",u); sub(/\?.*$/,"",u); print $1, u}' access.log \
  | LC_ALL=C sort | uniq -c | LC_ALL=C sort -k2,2 -k1,1nr \
  | awk '!seen[$2]++'      # 同一 IP 内计数已降序，首次出现的即该 IP 的 TOP1

最后的 awk '!seen[$2]++' 值得单独记：它利用"同一 IP 的计数已按降序排列"这一前提，只在某 IP 第一次出现时输出，等价于按键取 TOP1，而不需要保存每个 IP 的最大值。这是"用排序的确定性替代额外状态"的典型手法，也是面试官最想看到的加分点。

14.9 其他高频小工具

strace 与 perf 的取舍：想知道"程序在向内核要什么"用 strace，想知道"CPU 时间花在哪"用 perf；前者把每次系统调用变成额外的两次上下文切换，一次跟踪可能把 100 ns ~ 1 μs 的调用放大百倍，后者走采样、基本无侵入。

本章小结

自测题

Q1（辨析）一份日志每行可能包含多个 ERROR。分别写出"包含 ERROR 的行数"“ERROR 出现的总次数"“不含 ERROR 的行数"三条命令，并说明 grep -c 在这里为什么不够用。

Q2（推导）把 cmd 2>&1 > f 与 cmd > f 2>&1 的 fd 走向逐步画出，并解释为什么第一种写法会让"日志文件里看不到报错”。

Q3（计算）目录下有 20000 个 *.log，逐个 gzip。请估算 -exec gzip {} \; 与 -exec gzip {} + 的进程创建次数与数量级耗时差异，并说明 + 的三条使用限制。

Q4（设计）netstat -anp 在一台连接数很多的服务器上要跑十几秒且明显吃 CPU。请从数据来源层面解释原因，给出替代命令，并说明"容器里 ss -lntp 显示 pid=1“这一现象的成因。

Q5（设计）日志有 80 GB，可用内存 2 GB，要求输出访问量 TOP10 IP 与每个 IP 的 TOP1 URL。给出两种方案，说明各自的内存与磁盘代价，并指出哪一个前提被破坏时方案会失效。

面试高频问题与陷阱

延伸阅读

• man 1 grep、man 1 sed、man 1 awk（POSIX 语义以 man 1p 为准）、man 1 sort、man 1 uniq、man 1 find、man 1 xargs：本章所有参数行为的权威依据，尤其是 -exec ... + 的 {} 位置限制与 xargs 的分词规则。
• man 1 bash 的 REDIRECTION、Shell Grammar、SHELL BUILTIN COMMANDS（set、trap）三节：2>&1 的求值顺序、[[ ]] 条件表达式与 pipefail 的官方定义都在这里；man 1p sh 提供 POSIX 口径，用来判断哪些写法不可移植。
• man 8 ss、man 7 sock_diag、man 8 lsof、man 5 proc（/proc/net/* 与 /proc/<pid>/fd）：理解"内核侧过滤"与"用户态遍历 /proc“两条路线的性能差异。
• man 1 strace、man 1 perf-stat（含 perf stat 事件列表）、man 1 time（区分 shell 内建与 /usr/bin/time）。
• Nginx 官方文档 ngx_http_log_module（log_format 的 combined 默认格式与各变量定义）：14.8 节列切分推导的依据；jq 1.7 manual 的 -r、select、.[] 语义。
• 对照第 7 章 7.1 节（fd 表与 dup2）理解重定向的内核落点，对照第 16 章 16.2 / 16.4 节理解 ss 输出的 Recv-Q/Send-Q 与 TIME_WAIT/CLOSE_WAIT 的排查口径。