grep ERROR app.log从大量文本里挑出匹配的行,最常用的过滤入口。
约 1266 字大约 4 分钟
2026-05-14
Linux 的文本处理不靠一个全能工具,而靠一组各司其职的小命令,用管道串起来。新手最容易犯的错是“拿一把锤子敲所有钉子”——用 grep 硬抠 JSON、用 awk 干 sed 的活。这篇先把每个工具的“职责边界”划清楚,你才知道一个需求该交给谁。
弄清 grep、sed、awk、cut、sort、uniq、wc、xargs、jq 各自的职责边界,知道一个需求该用哪个工具、怎么组合。
grep ERROR app.log从大量文本里挑出匹配的行,最常用的过滤入口。
awk '{print $1}' access.log按列拆分、提取、计算,处理结构化文本的主力。
sort file | uniq -c排序后统计每种值出现多少次,做排行榜。
jq . data.json理解 JSON 结构,按字段路径提取,不要用 grep 硬抠。
| 工具 | 一句话职责 | 典型场景 |
|---|---|---|
grep | 按模式筛选行 | 从日志里挑出含 ERROR 的行 |
sed | 按规则编辑文本 | 批量替换、删除某些行 |
awk | 按列拆分、提取、计算 | 取 access.log 的第 1 列 IP、对某列求和 |
cut | 按固定分隔符截取列(awk 的轻量版) | 取 /etc/passwd 的用户名列 |
sort | 排序 | 为 uniq 做准备,或按数值大小排 |
uniq | 处理相邻重复行 | 配合 sort 统计每种值的数量 |
wc | 计数(行 / 词 / 字节) | wc -l 数日志有多少行 |
xargs | 把输入变成命令参数 | 把 find 的结果交给别的命令处理 |
jq | 处理 JSON | 从 API 返回里提取某个字段 |
记住这张表,遇到需求先问“这是筛选、是改写、是按列、还是统计”,自然就对应到工具。
绝大多数文本处理任务,是这三步的组合:
grep "ERROR" app.log | awk '{print $5}' | sort | uniq -c | sort -rn
# ① 筛出错误行 ② 取出错误类型 ③ 排序 ④ 计数 ⑤ 按次数排grep 把范围缩到相关的行awk / cut 抽出你关心的那一列sort | uniq -c 数数量,wc -l 数总数这个“筛 → 取 → 统计”的套路,在 日志统计实战 里会反复用到。
最常见的两个“拿锤子敲螺丝”:
grep 按行匹配很容易抠错或漏掉。结构化数据就该用 jq。sed 's/A/B/' 一句就够,不必动用 awk。工具选对了,命令往往短一截,也不容易出错。
文本处理的管道经常五六段长。不要写完整条再回车,而是从左往右一段一段加:先跑 grep ... 看输出对不对,再加 | awk ... 看,再加 | sort ……每加一段都确认“它的输出正是下一段需要的输入”。这个习惯能让调试从“盯着一团乱输出猜”变成“知道是哪一段出了问题”。
文本处理基本只读,但 sed -i 是例外
grep、awk、sort 这些默认只读、只输出,不改原文件,放心练。唯一要当心的是 sed -i(就地编辑)和重定向 >——它们会真的改文件。sed 想改文件前,先不带 -i 跑一遍看输出对不对;> 不要写成 grep x file > file(会先清空 file)。详见 管道与重定向。
| 误区 | 更稳妥的做法 |
|---|---|
用 grep 解析 JSON / 多层结构 | 结构化数据用 jq,按字段路径取才可靠 |
简单替换也上 awk | 纯替换 sed 's/a/b/' 就够,工具够用就好 |
| 一口气写完长管道再回车 | 从左到右逐段加,每段先确认输出 |
| 以为所有文本工具都安全 | sed -i 和 > 会改文件,先 dry-run 再动手 |
版权归属:Shuo Liu