find -exec 问题根源是 shell 对{}的错误切分，安全写法用+批量处理或sh-c封装；awk需结合sed预处理引号；grep上下文去重需--group-separator；脚本兼容性须检查shebang和posix语法。
为什么 find 加了 -exec 还是只处理第一个文件？
常见错觉是 find /path -name "*.log" -exec rm {} \; 会逐个执行，但实际中若路径含空格或换行，{} 会被 shell 错误切分。根本原因不是 find 本身，而是 sh -c 环境未隔离参数。
- 安全写法用
+替代\;：find /var/log -name "*.old" -exec gzip {} +—— 批量传入，避免 shell 重解析 - 必须单条处理时，加
sh -c封装：find /tmp -type f -name "temp_*" -exec sh -c 'echo "Processing: $1"; rm "$1"' _ {} \;，其中_占位$0，{}成为$1 - 别依赖默认
IFS；处理含空格文件前，先确认当前 shell 的IFS是否被改过（echo "$IFS" | cat -v）
如何让 awk 正确识别字段分隔符，而不是被引号或转义搞乱？
awk 默认按空白分割，但 CSV 或日志里字段常带引号、逗号嵌套、反斜杠转义——这时硬切会崩。它不原生支持 RFC 4180 解析，得靠策略绕过。
- 简单场景用
-F配合正则：awk -F'[[:space:]]+|,[[:space:]]*' '{print $2}' file.csv，跳过逗号前后空格 - 含双引号包裹字段时，先用
sed剥离引号再交给awk：sed 's/"\([^"]*\)"/\1/g' data.csv | awk -F, '{print $3}' - 真正复杂结构（如含换行的 CSV 字段）别硬刚
awk，改用python -c "import csv; [print(row[2]) for row in csv.reader(open('f'))]"
grep 显示匹配行上下文，但为什么 -A/-B 有时漏掉关键行？
grep -A 2 -B 1 "error" app.log 看似可靠，但若匹配行密集（如连续 5 行都含 error），-A 和 -B 会去重合并上下文，导致中间行被跳过。
- 用
--group-separator=$'\n'显式分隔组，避免误合并：grep -A 2 -B 1 --group-separator=$'\n' "timeout" *.log - 需要严格保留原始行号和顺序时，改用
awk模拟：awk '/timeout/{for(i=NR-1;i<=NR+2;i++)if(i in a)print a[i]; next} {a[NR]=$0}' *.log - 注意
grep对二进制文件默认静默跳过；加-a强制文本模式，否则可能漏掉看似“二进制”的日志片段
写完一个 Shell 脚本，怎么快速判断它在不同系统上会不会挂？
不是所有 Linux 发行版都用 bash；Alpine 默认 ash，CentOS 7 的 /bin/sh 是 dash，而你的脚本用了 [[ 或 $(( ))，一跑就报 command not found。
- 第一件事：查 shebang —— 用
#!/bin/bash就别指望/bin/sh兼容；要最大兼容，改用#!/usr/bin/env sh并只用 POSIX shell 语法 - 检查扩展语法：运行
shellcheck -s sh yourscript.sh，它会标出source（应为.）、let（应为expr或$(( ))不可用）等非 POSIX 用法 - 真实验证：在 Docker 里快速测：
docker run --rm -v $(pwd):/t alpine:latest sh -c 'cd /t && sh ./script.sh'，比手动搭环境快得多
Shell 能力进阶不是堆命令数量，而是清楚每个符号在哪个阶段由谁解释、在哪种边界条件下会失效。最常翻车的地方，永远是“我以为它在这里起作用”，其实它早被前一个管道或子 shell 吃掉了。
