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 吃掉了。