Bell Labs 文化特质
├── 学术自由 —— 研究者可以选择自己感兴趣的课题
├── 跨学科交流 —— 数学家、物理学家、工程师共处
├── 小团队高效协作 —— 核心开发团队始终很小
├── 工具文化 —— "先造工具，再用工具造更大的工具"
└── 实用主义 —— 解决真实问题，而非追求理论完美

# ❌ 不好的设计：一个命令做太多事
magic-tool --search "error" --replace "warn" --sort --output result.txt

# ✅ Unix 方式：每个工具做一件事，通过管道组合
grep "error" logfile.txt | sed 's/error/warn/g' | sort > result.txt

# 每个工具的职责清晰：
# grep — 从输入中筛选匹配行
# sed  — 对文本做替换
# sort — 排序

做一件事做好它的好处
├── 可靠性 —— 功能单一，bug 更少
├── 可测试性 —— 边界清晰，容易编写测试
├── 可复用性 —— 工具可以在不同场景中组合使用
├── 可替换性 —— 任何一个组件都可以被更好的实现替换
└── 学习成本 —— 每个工具的学习曲线都很平缓

# ✅ 好的输出：干净的数据，可以继续处理
ls -1 *.log
# output:
# access.log
# error.log
# system.log

# ❌ 不好的输出：装饰性的格式，难以被其他程序解析
ls --fancy *.log
# output:
# ╔══════════════╗
# ║ access.log   ║
# ║ error.log    ║
# ║ system.log   ║
# ╚══════════════╝

# 经典管道链：统计日志中最频繁的错误
cat /var/log/syslog | grep "error" | awk '{print $5}' | sort | uniq -c | sort -rn | head -10

# 分解每一环节：
# cat   — 读取文件内容
# grep  — 筛选包含 "error" 的行
# awk   — 提取第5列（进程名）
# sort  — 排序（uniq 要求输入已排序）
# uniq -c — 统计重复次数
# sort -rn — 按数量降序排列
# head  — 取前 10 条

# 第一步：用 shell 脚本快速原型
#!/bin/bash
# 简单的日志分析器原型
grep "$1" /var/log/syslog | wc -l

# 第二步：验证需求后，用更高效的工具重写
#!/bin/bash
# 优化版：使用 awk 替代 grep + wc
awk -v pattern="$1" '$0 ~ pattern {count++} END {print count}' /var/log/syslog

# 第三步：进一步优化性能
#!/bin/bash
# 处理大型日志文件：使用并行处理
find /var/log/ -name "*.log" -print0 | \
    xargs -0 -P $(nproc) grep -c "$1" | \
    awk -F: '{sum+=$NF} END {print sum}'

# ✅ 可移植的写法：使用 POSIX 标准工具
cat file.txt | grep "pattern" | wc -l

# ⚠️ 高效但不可移植的写法
grep -c "pattern" file.txt     # 大多数系统支持，但不是 POSIX 强制
grep -cP "pattern" file.txt    # -P（Perl 正则）仅 GNU grep 支持

跨平台脚本常见陷阱
├── #!/bin/bash vs #!/bin/sh —— bash 不一定存在
├── GNU 工具 vs BSD 工具 —— sed、grep、find 的选项差异
├── /proc 文件系统 —— 仅 Linux 支持
├── 命令选项 —— GNU 长选项（--help）不是 POSIX 标准
├── 正则表达式 —— BRE vs ERE vs PCRE
└── 文件路径 —— 大小写敏感性因系统而异

# ✅ 好的行为：成功时无输出
cp file.txt backup/
echo $?  # 0 = 成功

# ❌ 不好的行为：成功时输出噪音
cp file.txt backup/
# "File successfully copied to backup/file.txt!"
# "Operation completed at 2026-05-10 10:30:45"
# "Have a nice day!"

# Unix 程序通过退出码（exit code）报告结果
# 0 = 成功，非 0 = 失败

#!/bin/bash
# 良好的脚本模式：检查每一步的退出码
set -euo pipefail  # -e: 出错即退出; -u: 未定义变量报错; -o pipefail: 管道中任一命令失败即失败

grep "pattern" input.txt > results.txt
sort results.txt > sorted.txt
uniq sorted.txt > unique.txt

echo "处理完成，共 $(wc -l < unique.txt) 条唯一结果"

# 示例：选择正确的数据结构
# 场景：统计网站访问量 Top 10 的 IP 地址

# 方法 1：简单但低效 —— 多次遍历
cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# 方法 2：单次遍历，使用关联数组（awk）
awk '{count[$1]++} END {for (ip in count) print count[ip], ip}' access.log | sort -rn | head -10

# 方法 3：使用专门的工具
goaccess access.log --log-format=COMBINED

# BusyBox 将 200+ 个 Unix 工具编译成一个 ~1MB 的二进制文件
# 通过符号链接实现多命令调用

# Alpine Linux（Docker 默认基础镜像）就基于 BusyBox
docker run alpine:3.19 ls -la /bin/
# 大部分命令都是指向 busybox 的符号链接

docker run alpine:3.19 wc -c /bin/busybox
# 约 1 MB

Rule 1:  你无法判断程序会在哪里消耗时间。
         → 先让代码正确工作，再做 profiling 优化。

Rule 2:  测量。（Measure.）
         → 不要做没有数据支撑的优化。

Rule 3:  当 n 很小时，花哨的算法很慢，n 通常很小。
         → 不要过早使用复杂算法。

Rule 4:  花哨的算法比简单的算法慢，
         当 n 很小时，n 通常很小。
         → 再次强调：简单优先。

Rule 5:  数据占主导地位。
         → 选择正确的数据结构。

Rule 6:  没有 Rule 6。
         → 保持幽默感，不要过度教条。

Unix 哲学 → 现代 Web 架构
├── 做一件事做好它 → 微服务架构
├── 管道组合 → 消息队列 / 事件驱动
├── 文本流 → JSON / HTTP API
├── 沉默即金 → 遵循 HTTP 状态码规范
└── 可移植性 → 容器化（Docker）

# Unix 哲学在 CI/CD 管道中的体现
# 每个步骤做一件事，通过管道串联

#!/bin/bash
set -euo pipefail

# Step 1: 拉取代码
git clone "$REPO_URL" && cd "$REPO_NAME"

# Step 2: 安装依赖
npm ci --production

# Step 3: 运行测试
npm test

# Step 4: 构建
npm run build

# Step 5: 部署
rsync -avz dist/ "$DEPLOY_SERVER:/var/www/html/"

echo "部署成功"