grep命令实战：从文本匹配到Shell脚本高效用法

1. 从RHCSE课程里的SHELL第六讲说起：grep到底解决什么问题

接触过RHCSE的人都知道，整个认证体系里SHELL脚本编程占了相当大的比重，而在我自己备考和带新人的过程中，grep永远是绕不开的那个命令。每次讲到SHELL06这一节，我都会先问一个问题：你在Linux服务器上排查问题的时候，最常用的命令是什么？答案几乎都是grep。这其实很有道理，因为grep解决的并不是某个单一的技术问题，而是一个贯穿所有运维场景的通用需求——在大批量文本里快速锁定我想要的那一行。

你可能会有疑问，为什么grep这么基础的东西值得单独开一节来讲？恰恰因为它基础，反而被用得太随意。很多人对grep的印象停留在"在文件里搜个关键字"，但实际用起来，grep可以做精细的模式匹配、可以做上下文提取、可以配合管道完成复杂的数据过滤、可以写进脚本做条件判断。学不学得透，直接决定了你写出来的SHELL脚本是"能跑"还是"好维护"。

这篇文章不是按照RHCSE考纲给你画重点，而是从实际干活的角度，把我在真实环境里用grep的经验、踩过的坑、以及那些教科书上不会细讲的细节一次说清楚。适合正在备考RHCSE的人，也适合日常跟Linux打交道、想提升命令效率的运维和开发。文章里的命令我全部在CentOS Stream和Ubuntu上实测过，涉及到的正则语法在GNU grep和POSIX模式下都做过验证，你可以放心照着操作。

2. grep的工作机制：为什么它比编辑器查找快那么多

很多人第一次意识到grep厉害，是在处理超大日志文件的时候。用vim打开一个几个GB的日志文件，光是加载就要卡半天，更别提在里面搜索了。但grep哪怕面对几十GB的文件，也只需要几秒钟就能给出结果。这背后的原理不搞明白，你用grep的时候心里就没有底。

2.1 流式处理模型

grep的核心处理方式叫流式读取，它不会把整个文件加载到内存里，而是逐行读取、逐行匹配、逐行输出。换句话说，grep的输入可以是文件，也可以是管道传来的数据流，它根本不关心你给它的数据总量有多大，反正都是处理完一行丢一行。

这个特性带来两个直接的收益。第一，内存占用极低，不管你处理的是100MB还是100GB的文件，grep的内存消耗都保持在一个很小的稳定值附近。第二，配合管道使用的时候，grep可以一边接收上游数据一边输出结果，不需要等上游全部执行完才开始工作。所以你在命令行里写tail -f app.log | grep ERROR的时候，日志每产生一行新的ERROR，屏幕上就会立刻多一行输出，这就是流式处理的价值。

对比一下文本编辑器或者IDE的全局搜索功能，它们通常需要先把文件读进内存建立索引，然后再做查询，在面对大文件的时候体验就会差很多。理解了这个区别，你就知道什么时候该用grep、什么时候不该用grep了。

2.2 退出状态码：脚本里最容易被忽略的宝藏

grep有一个大多数新手完全不知道的特性，它的退出状态码不是简单的"成功或失败"，而是三种状态。匹配到内容返回0，没有匹配到返回1，执行过程出错返回2。这个设计在交互式命令行里似乎没什么用，但在SHELL脚本里就是金矿。

举个实际例子。你要写一个监控脚本，检查某个服务是否还在正常响应，其中一个判断依据是日志里有没有出现关键词。如果只是人肉去命令行里看结果，你根本不会在意退出码，但写进脚本里，你就可以直接基于退出码做分支控制，完全不需要再用$?去额外判断。

bash复制#!/bin/bash

LOG_FILE="/var/log/myapp/app.log"

if grep -q "FATAL ERROR" "$LOG_FILE"; then
    echo "检测到致命错误，需要立即处理"
    # 在这里可以接上告警命令，比如发邮件或者调Webhook
else
    echo "日志状态正常，没有致命错误"
fi

注意这里我用了一个-q参数，它的作用是静默模式，grep不会在屏幕上输出任何匹配结果，只设置退出状态码。这是脚本里最常见的grep用法，效率最高，输出最干净。

2.3 基础正则与扩展正则的路线选择

grep默认使用的是基础正则表达式，而egrep或者grep -E使用的是扩展正则表达式。两者的核心区别在于元字符的转义规则。

在基础正则里，+、?、|、()这些字符如果不加反斜杠，就是普通的字面字符，只有加上反斜杠才会变成特殊含义。比如你要匹配"apple"或"orange"，基础正则得写成apple\|orange，而扩展正则只需要apple|orange。扩展正则的语法更接近其他编程语言的正则习惯，可读性也更好。

我个人的建议是，写脚本和做复杂匹配的时候直接用grep -E，或者干脆用egrep。不要为了显摆自己记得住转义规则而在基础正则里绕来绕去。但有一个前提是你要能看懂别人写的旧脚本里的基础正则写法，毕竟生产环境里还有很多老脚本是这么写的。

3. 正则表达式实战：从元字符到模式组合

很多人觉得正则表达式难，是因为一下子上来就背一大堆元字符。我的经验是，正则这东西不需要刻意背，你只需要理解三个层面的东西就够了：字符、位置、数量。所有的正则语法归根结底都是在描述这三件事。

3.1 字符类：匹配"某一种"字符

最基础的字符匹配是精确匹配，你写什么字符就匹配什么字符。但实际场景里你往往需要匹配一个范围的字符，这时候就要用字符类。

bash复制# 匹配文件中的所有IPv4地址段的一部分
grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" access.log

[0-9]表示匹配0到9之间的任意一个数字，{1,3}表示前面的字符或字符组出现1到3次。\.是因为在正则里.有特殊含义（匹配任意字符），要匹配字面上的小数点就必须转义。

字符类里还有几个便捷写法：[[:space:]]匹配所有空白字符，[[:alpha:]]匹配所有字母，[[:digit:]]匹配所有数字。这些POSIX字符类在写脚本的时候比[a-zA-Z0-9]这种写法更规范，也更不容易出错。

3.2 锚点与边界：把匹配锁定在特定位置

有时候你要匹配的内容不是"只要出现在文本里就算"，而是必须出现在行首、行尾或者单词边界上。这时候不带锚点的正则就会产生很多误报。

bash复制# 匹配以ERROR开头的行
grep "^ERROR" app.log

# 匹配以timeout结尾的行
grep "timeout$" app.log

# 精确匹配单词error，而不是errors、error404这些包含error的字符串
grep -w "error" app.log

-w参数很多人不知道，它代表word boundary，即单词边界。这个参数在处理英文日志的时候非常有用，因为你不希望搜索一个词的时候把包含这个词的更长单词也匹配出来。

我踩过一个非常经典的坑：有一次排查线上问题，我看日志里有一条info和一条information，用grep "info"匹配的时候两条都出来了，导致我以为某个模块已经初始化完成，但实际上是另一条无关日志在干扰。后来加上-w参数才过滤干净。这种小细节在紧急排障的时候就可能造成误判，多花半小时定位问题。

3.3 量词与分组：从简单匹配到复杂模式

当你需要匹配重复出现的字符时，量词就派上用场了。*表示前面的字符出现0次或多次，+表示出现1次或多次，?表示出现0次或1次，{n}表示恰好出现n次，{n,m}表示出现n到m次。

分组的概念更关键。用圆括号把一部分正则包起来，一来可以把这部分当作整体应用量词，二来可以提取匹配的内容。

bash复制# 匹配日期格式，兼容2024-01-15和2024/01/15
grep -E "2024[-/]0[1-9][-/][0-9]{2}" data.txt

# 匹配连续两次出现的单词，比如"hello hello"
grep -E "([a-z]+) \1" text.txt

第二个例子里的\1是反向引用，表示"和第一个分组匹配到的内容完全相同"。这在查找重复数据的时候非常好用。

3.4 正则的三个错误认知

关于正则，我看到最多人有这几个误解。第一个是觉得"只要能跑通就是对的"，实际上很多正则写得不严谨，会把不该匹配的文本也捞出来。第二个是认为"正则匹配越复杂越好"，实际上在生产环境里，正则的复杂度直接影响匹配性能，一个嵌套很深的分组正则可能让grep的处理速度慢上几十倍。第三个是忽略转义字符的层级关系，在SHELL里正则先被Shell解析一次，再被grep解析一次，所以在命令行写正则和在脚本里写正则，转义的方式可能完全不同，这点后面会单独展开。

4. 高频参数实战：按场景选对选项

grep的参数有几十个，但日常真正高频用到的其实就那么十几个。我不打算一个一个照着man手册念，而是根据实际场景来串一遍，这样你遇到类似问题的时候可以直接对号入座。

4.1 过滤组合：-v反向匹配与多模式匹配

-v参数是反向匹配，输出所有不包含指定模式的行。它最常见的用途是过滤掉你不关心的内容，保留有价值的信息。

bash复制# 排除所有空行
grep -v "^$" config.ini

# 排除注释行（以#开头的行）
grep -v "^#" nginx.conf

# 同时排除空行和注释行
grep -vE "^$|^#" nginx.conf

注意看第三个例子，我用了-E来表示扩展正则，然后用|连接了两个模式。当你有多个需要排除的条件时，用正则的或逻辑是最简洁的写法。

还有一种情况是你需要同时匹配多个模式中的任意一个。有人会写grep "pattern1" file | grep "pattern2"，这实际上是"同时包含pattern1和pattern2"的逻辑与关系。如果你要的是逻辑或关系，应该用grep -E "pattern1|pattern2"，或者用grep -e pattern1 -e pattern2。

4.2 上下文控制：-A、-B、-C的使用场景

排查问题的时候，你往往不只是想看匹配到的那一行，而是需要看它前后发生了什么。-A后面跟数字表示显示匹配行之后的行数，-B表示之前，-C表示前后都显示。

bash复制# 查看异常堆栈信息，异常通常不止一行
grep -A 20 "Exception" app.log

# 查看错误发生前的日志上下文
grep -B 10 "Connection refused" app.log

# 前后各看5行
grep -C 5 "OutOfMemoryError" app.log

这个参数在排查程序崩溃、数据库报错这些问题的时候几乎是刚需。比如Java应用抛出的异常堆栈通常有十几行，你只匹配第一行"Exception"根本看不到完整的调用链，加上-A 20就能把整个堆栈打出来。

4.3 只输出匹配部分：-o的妙用

默认情况下，grep输出的是整行内容。但你有时候只关心匹配到的那个片段，尤其是做数据提取的时候。-o参数让grep只输出匹配到的部分，不输出整行。

我给你一个更实用的例子。从日志中提取所有的IP地址，然后统计每个IP出现的次数：

bash复制# 提取所有IP，sort排序，uniq去重计数
grep -oE "[0-9]{1,3}(\.[0-9]{1,3}){3}" access.log | sort | uniq -c | sort -rn

这条命令在分析Nginx访问日志的时候非常好用。-o把每个IP单独提取出来，sort让相同的IP排在一起，uniq -c统计每个IP出现的次数，最后的sort -rn按次数从大到小排序。一行命令就能看出哪些IP在频繁访问你的服务器。

4.4 递归搜索：-r处理多文件目录

在多个文件里搜索的时候，不需要写一长串文件列表，直接让grep递归遍历目录。-r参数可以配合--include指定文件类型，只搜索符合条件的文件。

bash复制# 在/var/log目录下所有.log文件里搜索"500"
grep -r "500" /var/log --include="*.log"

# 排除某种文件类型
grep -r "password" /etc --exclude="*.db"

# 显示文件名的同时显示行号和匹配内容
grep -rn "Listen 80" /etc/httpd/

我特别建议加上-n参数，它会在输出中带上行号。单个文件还好，一旦在多个文件里搜索，没有行号几乎没法定位。

4.5 二进制文件处理：-a与-I

默认情况下，grep遇到二进制文件会输出一行类似"Binary file xxx matches"的提示，这其实是为了避免二进制内容污染你的终端。但有时候你确实需要在二进制文件里搜索字符串，比如分析一个可执行文件里有没有包含某个配置路径。

bash复制# 强制把二进制文件当文本处理
grep -a "mysql" /usr/sbin/mysqld

# 完全跳过二进制文件
grep -rI "error" /var/log/

-I和-a恰好相反。在递归搜索日志目录的时候，如果目录下有二进制文件，-I可以避免它们干扰结果。

5. grep与管道组合：从单一命令到数据处理链路

grep单独用只是文本过滤，但一旦跟管道组合起来，它就变成了数据处理链路中的关键节点。实际运维中几乎不可能只用grep解决一个问题，更多时候是多个命令配合。

5.1 进程管理与grep的经典组合

ps aux | grep大概是Linux命令行里被使用频率最高的一条组合命令。但这里有个很多人都会踩的坑。

bash复制# 这条命令会匹配到自己的grep进程
ps aux | grep java

# 看看输出结果
root  12345  0.5  2.3 123456 7890 ?  Ss  10:30   0:01 java -jar app.jar
root  23456  0.0  0.0 112712  964 pts/0  S+  10:45   0:00 grep --color=auto java

发现没有？grep java这条命令本身也包含"java"这个字符串，所以grep会把自己的进程也匹配出来。这就是热搜词里提到的"ps aux | grep 脚本名 pid一直变"的问题根源。

解决办法有两个。第一个是用正则的字符类技巧，让grep的模式匹配不到自己：

bash复制ps aux | grep "[j]ava"

用[j]而不是j，这样grep命令行里的模式是[j]ava，它本身不包含连续的"java"字符串，所以不会匹配到自己。第二个方法是用grep -v grep过滤掉：

bash复制ps aux | grep java | grep -v grep

第一种写法更优雅，也成了不少人的习惯写法，但第二种可读性更好，新手也容易理解。

另一个相关的坑是pid一直变的问题。如果你看到脚本里pid=$(ps aux | grep myapp | grep -v grep | awk '{print $2}')这种方法获取PID，在某些环境下可能会匹配到多个进程，导致PID获取错误。更可靠的方式是用pgrep命令，但如果你还在用grep方式，一定要确保匹配模式足够精确，最好加上-w参数或者用完整的启动命令来匹配。

5.2 日志追踪组合：tail、grep与实时监控

tail -n 50 | grep也是热搜词里出现过的组合。它解决的问题是：日志文件很大，你不需要全文搜索，只想看最近几十行里面有没有关键信息。

bash复制# 查看nginx错误日志最后50行中属于PHP的错误
tail -n 50 /var/log/nginx/error.log | grep "PHP"

# 实时追踪日志文件新增内容，并过滤出ERROR级别
tail -f /var/log/app.log | grep "ERROR"

# 实时追踪并带上下文
tail -f /var/log/app.log | grep -A 5 "CRITICAL"

tail -f配合grep之后，终端只会显示匹配的行，在调试的时候非常清爽。但因为grep默认有缓冲，你可能发现输出有延迟，这时候可以加--line-buffered参数让grep逐行输出，日志实时性更好：

bash复制tail -f /var/log/app.log | grep --line-buffered "ERROR"

这个参数在管道场景里的作用很多人不知道。默认情况下，grep在管道里的输出是块缓冲的，要攒够一定量才输出，在实时日志场景下体验很差。加上--line-buffered就直接解决了。

5.3 配置文件排查组合：cat、grep与重要配置项提取

排查服务配置问题的时候，你经常需要从配置文件里快速提取非注释、非空行的有效配置。来看一段我实际处理nginx配置的经验：

bash复制# 去掉nginx.conf里所有注释和空行，留下有效配置
grep -vE "^\s*#|^\s*$" /etc/nginx/nginx.conf

# 只查看server_name相关的配置行
grep -n "server_name" /etc/nginx/conf.d/*.conf

这里注意正则里的^\s*#，它表示行首可能有空格或制表符，然后才是注释符号#。直接写^#会漏掉前面有缩进的注释行。同理，^\s*$匹配的是可能包含空白字符的空行。

5.4 awk和sed的配合时机

grep负责"找"，awk负责"处理"，sed负责"替换"，三者组合起来能做很复杂的数据处理。

bash复制# 从access.log里找出所有状态码为500的请求的响应时间
grep "HTTP/1.1\" 500" access.log | awk '{print $NF}'

# 从grep结果里提取文件路径并去重
grep -r "root /var/www" /etc/nginx/ | sed 's/.*root //' | sort -u

我的建议是，管道里命令的个数不要超过四五个，超过之后调试会变得很痛苦。如果逻辑确实复杂，把它写成脚本，每一步的输出都加上适当的调试信息，可维护性会好很多。

6. 硬核排查实录：一个定位了整整半天的问题

前面讲的都是方法论，这一节用一个真实案例把grep在排障中的完整链路串起来。这个案例来自我之前处理过的一个生产环境问题，现象是某个Java服务每过一段时间就会无响应，重启之后恢复，过一段时间又复发。

第一轮排查，我先看服务日志里最近的报错：

bash复制tail -n 1000 /var/log/myapp/application.log | grep -iE "error|exception"

搜出来的内容比较多，但大部分是业务逻辑里的常规异常处理，没有明显的OOM或者严重错误。这时候我把范围扩大，看错误发生的时间是否集中在某个时段：

bash复制grep -E "2024-03-1[0-9]" /var/log/myapp/application.log | grep -c "ERROR"

-c参数用来统计匹配的行数。这里我看看每天ERROR的数量分布，发现完全没有规律，跟时间无关。

第二轮排查转向系统层面。我怀疑是资源瓶颈，检查了进程的CPU和内存占用：

bash复制ps aux | grep "[m]yapp" | awk '{print $3, $4, $11}'

CPU和内存都正常。又开始怀疑是连接数问题，用ss查看端口连接：

bash复制sudo ss -lntp | grep 8080

没错，这一场景正好对应热搜词里的sudo ss -lntp | grep 8080。8080端口在监听，连接数也没有明显异常。到这里，常规手段基本都试过了，问题还没定位。

第三轮我换了个思路，直接看服务从启动到现在完整的关键事件时间线：

bash复制grep -nE "Started|Shutdown|Halt|Fatal|OutOfMemory" /var/log/myapp/application.log | head -n 100

这才发现了问题。服务在每次无响应之前，都有一条Shutting down的记录，但这条日志级别是INFO，之前被我用grep "ERROR"过滤掉了。继续深挖：

bash复制grep -A 30 "Shutting down" /var/log/myapp/application.log | grep -iE "reason|cause|timeout|exception"

最终定位到是某个外部接口调用的连接池在特定条件下触发了优雅关闭逻辑，导致服务假死。

这个案例的教训对排查任何问题都适用：一开始用grep做精确匹配，很容易把真正有价值的上下文给过滤掉。所以我现在排查问题的习惯是，先用宽泛的匹配看全貌，再逐步缩小范围，绝对不能一上来就只搜ERROR这种过于精确的模式。这也解释了我为什么在上一节反复强调-A和-B参数的重要性。

7. 写SHELL脚本时grep的正确姿势

SHELL脚本里的grep跟命令行里的grep是不同的物种。命令行里只要求结果正确，脚本里还要求输出可控、健壮性足够。很多时候脚本出问题，不是逻辑写错了，而是grep在脚本环境下的行为跟你在终端里手动执行时不一样。

7.1 变量与引号：脚本里最容易翻车的地方

在脚本里使用grep时，如果你把待搜索的模式定义成变量，然后不加引号地传给grep，很容易出问题。

bash复制#!/bin/bash

PATTERN="error: connection refused"
# 这种写法是有问题的，PATTERN中的空格会被shell拆成多个参数
if grep -q $PATTERN /var/log/app.log; then
    echo "找到错误"
fi

# 正确写法，用双引号把变量包起来
if grep -q "$PATTERN" /var/log/app.log; then
    echo "找到错误"
fi

至于为什么必须加双引号，涉及Shell的字段拆分规则：不加引号的变量会被Shell按空格、制表符、换行符拆分成多个单词，于是你的模式就被拆碎了。这个坑连写了好几年脚本的人也可能踩。

7.2 循环里的grep：性能陷阱

在循环里反复调用grep是脚本性能的大忌。比如你要检查多个文件里是否存在某个关键词：

bash复制# 这段代码在文件数量多的时候会非常慢
for file in /var/log/myapp/*.log; do
    if grep -q "ERROR" "$file"; then
        echo "$file 包含ERROR"
    fi
done

# 更高效的做法，用grep -l一次性输出匹配的文件列表
for file in $(grep -rl "ERROR" /var/log/myapp/); do
    echo "$file 包含ERROR"
done

-l参数只输出包含匹配内容的文件名，不输出具体行。这种方式一次grep就完成了所有文件的扫描，比在循环里一个个调grep快得多。原理也很简单，循环里多次启动grep进程，每次都要打开文件、读取、关闭，进程启动的开销被重复了很多次。

7.3 grep与set -e冲突

如果你在脚本开头写了set -e（遇到错误就退出），那就要特别注意grep的退出码了。set -e的语义是，只要哪条命令返回非零退出码，整个脚本立即退出。而grep匹配不到内容时返回1，会被set -e当成"出错"而退出脚本。

bash复制#!/bin/bash
set -e

# 如果文件里没有ERROR，grep返回1，脚本会直接退出
grep -q "ERROR" /var/log/app.log
echo "检查完成"   # 这行永远不会执行

解决办法是给grep加上|| true兜底，或者把它放在if语句的条件里。放在if条件里是更推荐的做法，因为if语句本身会处理非零退出码，不会触发set -e。

7.4 正则里特殊字符的处理

当你要搜索的字符串里包含正则元字符时，比如搜索一个包含句号的IP地址，你面临的问题是：这个句号在正则里表示"任意字符"而不是字面的句号。如果你不做转义，grep "192.168.1.1"可以匹配到192x168x1x1这种不是IP的内容。

当你想要grep完全按照字面意思搜索，不把任何字符当正则来解析，使用-F参数（fixed string）。比如：

bash复制# 从文件里搜索字面的"192.168.1.1"，句号就是句号
grep -F "192.168.1.1" /var/log/app.log

# 如果要搜索的内容里有很多特殊字符，-F尤其好用
grep -F "GET /api/v1/user?name=zhangsan&age=25" access.log

热搜词里提到的"bash grep 不要正则匹配"其实就是这个需求。当你只是单纯想找一段字符串，而不是做模式匹配，-F可以避免一整套转义问题，性能也更好，因为字面匹配比正则匹配更快。

7.5 处理大小写和不规则文本

日志里的错误信息有时候是"error"，有时候是"ERROR"，还有时候是"Error"。你不能假设所有日志都遵守统一的大小写规范。-i参数忽略大小写，适合这时候用：

bash复制grep -i "timeout" /var/log/app.log

但要注意，-i在某些场景下会带来误报。比如你搜的是"select"，忽略大小写后"SELECT"、"Select"都会被匹配，这在SQL相关场景里可能是你想要的，但在普通文本场景里可能会匹配出你不期望的内容。所以-i要不要加，取决于你对目标文本格式的把握。

7.6 颜色和格式的控制

交互式终端里，grep会用颜色高亮匹配到的内容，这在人肉查看时很方便。但如果你把grep的输出重定向到文件，或者通过管道传给其他程序，颜色转义字符会混进数据流里，导致下游处理出错。这时候用--color=never显式关闭颜色。

bash复制# 把grep结果写入文件，不加参数在部分环境会带上颜色转义码
grep --color=never "ERROR" /var/log/app.log > /tmp/errors.txt

另一个类似的参数是-h，在多个文件搜索时不显示文件名前缀。比如你用grep -r遍历目录时，输出会带上每个匹配行所属的文件名，有时候这信息是干扰，可以用-h去掉。

8. 对后辈的一句话：为什么SHELL06要从grep学起

我见过不少新人学RHCSE，刚开始接触SHELL脚本就急着写复杂逻辑，结果卡在处理文本数据上寸步难行。说到底，Linux系统本质上就是一个文本处理系统，配置文件是文本，日志是文本，命令输出是文本，几乎一切都以文本形式存在。而grep就是你在这个文本世界里最基础、最趁手的探测工具。

我特别建议你在学习的时候养成一种习惯：拿到任何一份不熟悉的日志、配置或者命令输出，第一反应就是想想怎么用grep从里面提取关键信息。比如看到/etc/passwd文件，你就想想怎么找出所有能登录Shell的用户；看到Nginx的access日志，你想想要统计哪些接口被调用得最频繁。你在这种练习上花的时间，回报率远远高于背命令参数。

还有一个小技巧值得分享。把你自己最常用的grep模式整理成一个脚本或者别名文件。我自己的~/.bashrc里就存了不少精心调校的grep别名，比如：

bash复制alias grep='grep --color=auto'
alias grepn='grep -n'
alias grepi='grep -i'
alias grepe='grep -E'
alias grepf='grep -F'

这些别名不是花架子，它们能在每天无数次敲命令的过程中，实实在在地节省时间，也减少因为参数拼写错误导致的重复输入。

grep这个命令看起来简单，但真的值得花时间深入。把正则基础打牢、把常用参数练熟、把脚本里的边界情况想清楚，你的SHELL水平会上一个台阶。后面学awk、sed这些工具的时候，你会发现它们的处理逻辑跟grep有相似之处，到时候再上手就会顺利很多。