刚学linux总卡在ls和cd之后，是因为未建立“命令—场景—反馈”闭环：只记语法不验证效果，如背ls -l字段却不观察权限修改后的实际输出，或记cd ..却未通过pwd确认路径变化；真实学习应是“执行→观察→改动→再执行→对比差异”。
为什么刚学 Linux 总是卡在 ls 和 cd 之后？
因为没建立「命令—场景—反馈」的闭环。比如只记 ls -l 输出字段含义，却不验证自己改了权限后 ls -l 真实变化；只背 cd .. 是返回上层，却没试过连续敲三次 cd .. 后 pwd 输出什么。真实学习节奏应该是：输一条命令 → 看输出 → 改点东西（比如新建个文件、改个权限）→ 再输一遍 → 对比差异。
常见卡点：
- 看到
~就以为是“家目录”，但cd ~和cd效果一样，而cd ~/tmp才真正用到它 -
mkdir报错No such file or directory，其实是父路径不存在，该加-p而不是反复cd进去再建 -
rm删除失败，不是权限问题，而是当前目录下有同名子目录干扰了通配符匹配（如rm *.log匹配到logs/目录）
grep 为什么搜不到明明存在的文本？
本质是正则表达式和输入流理解偏差。默认 grep 只处理行，不跨行；只读标准输入或指定文件，不递归进子目录；区分大小写，且对特殊字符（如 .、*、$）按正则解释而非字面意思。
实用组合：
- 搜整个项目里的
api_key（忽略大小写、递归、显示行号）：grep -rni "api_key" ./src/ - 确认某进程是否在运行（避免匹配到 grep 自身）：
ps aux | grep "[n]ginx"—— 方括号绕过自身匹配 - 过滤掉注释和空行：
grep -v "^#\|^$" config.conf - 想精确匹配单词
error，不是errors或enderror：grep -w "error" log.txt
什么时候该用 find 而不是 ls 或 grep？
find 是路径遍历引擎，ls 是目录快照查看器，grep 是文本流过滤器。三者职责不同，混用必然出错。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
典型误用场景：
- 想删掉 7 天前的
.log文件，写成ls -t *.log | head -n 10 | xargs rm—— 错：shell 展开*.log时已固定文件列表，ls -t排序无效，且不检查修改时间 - 正确做法：
find /var/log -name "*.log" -mtime +7 -delete - 想找所有包含
TODO的 Python 文件：find . -name "*.py" -exec grep -l "TODO" {} \;，而不是grep -r "TODO" *.py（后者不进子目录） -
find的-exec和xargs性能差异大：小文件用-exec安全；大量文件用xargs更快，但要注意空格路径需加-print0 | xargs -0
systemctl 启动服务失败，日志在哪看？
别急着重装或改配置，先确认 unit 文件是否加载、依赖是否满足、启动命令是否真能执行。
排查顺序：
- 查服务状态：
systemctl status nginx—— 注意看 Active 行后面是active (running)还是failed，以及 Loaded 行是否显示配置路径 - 看最近 20 行日志：
journalctl -u nginx -n 20；若服务根本没起来，加--since "2 minutes ago"更准 - 确认配置语法：
nginx -t（对 nginx），httpd -t（对 httpd），很多失败源于配置文件语法错误，systemctl不会主动校验 - 临时禁用依赖项测试：
systemctl disable docker.socket（如果怀疑 socket 激活冲突） - 注意用户上下文：用
systemctl --user启的服务，sudo systemctl看不到，反之亦然
最常被忽略的是 SELinux 上下文或 capability 限制——比如服务要绑定 80 端口却没 cap_net_bind_service，journalctl 里只会报 Permission denied，得配合 ausearch -m avc -ts recent 查拒接记录。
