Shell 的本质是基于文本流（stdin/stdout/stderr）的协作系统，命令间通过纯文本传递数据；理解数据流向、善用调试技巧、规范脚本编写，比死记命令更重要。
别背命令，先理解 Shell 的“数据流”本质
Linux 命令行不是功能菜单，而是一套基于文本流（stdin/stdout/stderr）的协作系统。你敲的每个命令，本质是在接收、处理、转发纯文本——ls 输出的是文件名列表（换行分隔），grep 读的是行，awk 默认按空格切字段，sort 排的是整行字符串。不理解这点，就容易陷入“这个命令怎么单独用”的误区。
实操建议：
- 养成加
echo和cat验证数据形态的习惯，比如：ls -l | head -3
看前 3 行长格式输出，再试ls -l | awk '{print $9}' | head -3确认是否只取了第 9 列（文件名） - 遇到陌生命令，先跑
man <command></command>看 SYNOPSIS，重点关注它「从哪读」（如[FILE]或-）和「往哪写」（如stdout） - 拒绝一次性写超长管道链；用
tee中间暂存调试，例如：ps aux | grep nginx | tee /tmp/nginx-pids | wc -l
掌握 find + xargs / -exec 的真实分工
很多人卡在“怎么批量删日志”“怎么改一堆配置里的 IP”，核心其实是没理清 find 负责“找路径”，后续动作要靠 xargs 或 -exec 触发。它们不是可互换的语法糖，而是有明确边界：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
find /var/log -name "*.log" -mtime +30只是列出路径，不执行任何删除 -
find /var/log -name "*.log" -mtime +30 -delete安全性低，不支持复杂逻辑（如先stat再判断） -
find /var/log -name "*.log" -mtime +30 -print0 | xargs -0 rm更可靠：用\0分隔路径，防空格/换行导致误切 -
find /etc -name "nginx.conf" -exec sed -i 's/192.168.1.1/10.0.0.1/g' {} \;中的{}是占位符，\;是-exec必需的终止符，漏掉会报错find: missing argument to '-exec'
用好 history 和 Ctrl+R，但得知道它们查什么
history 默认只存最近 1000 条（由 HISTSIZE 控制），且不自动同步多终端会话。你以为刚在另一个窗口 ssh 执行过的命令能 Ctrl+R 搜到？大概率搜不到——因为历史记录还没刷进 ~/.bash_history。
- 让历史实时追加：在
~/.bashrc加export PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
- 扩大存储量：
export HISTSIZE=5000
和export HISTFILESIZE=5000
-
Ctrl+R搜索时，输入关键词后按Ctrl+O可重复执行匹配项（不用回车再敲一遍） - 敏感命令如
mysql -uroot -p123456会被记入历史，可用set +o history临时关闭，或加空格让 bash 跳过记录（需设置HISTCONTROL=ignorespace）
别硬扛复杂任务，该上脚本就上，但别写“假脚本”
所谓“假脚本”，是指把一串命令复制粘贴进 vim test.sh，却不加 #!/bin/bash、不设 set -euo pipefail、不处理参数、不校验前置条件。这种脚本在自己机器跑通一次，换环境就挂。
- 最小可用模板：
#!/bin/bash set -euo pipefail <p>if [[ $# -ne 1 ]]; then echo "Usage: $0 <target_dir>" >&2 exit 1 fi</p><p>target="$1" if [[ ! -d "$target" ]]; then echo "Error: '$target' is not a directory" >&2 exit 1 fi</p><p>find "$target" -name "*.tmp" -delete
- 参数带空格？必须用
"$1"，不能写$1；路径含变量？优先用"${HOME}/logs"避免意外展开 - 临时调试加
echo不如用set -x，它会自动打印每行执行前的变量展开结果
真正卡住的从来不是命令记不全，而是对数据流向没感觉、对错误边界没预判、对工具组合没设计意识。这些没法靠背手册补，只能在修一个又一个线上故障时，反复问自己：“它到底在读什么？往哪写了？中间哪一步可能断？”
