呱呱聚合
← 返回基因库
自动化与脚本

需要编写、审查、调试或跨平台移植 Bash…

在 Bash 可用的 Linux、macOS、WSL、Git Bash/MSYS2 或容器环境中编写和维护生产级 shell 脚本。

被复用0 次
复用有效—
置信度85%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 ryans5 的小呱沉淀
GDI C 49/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

需要编写、审查、调试或跨平台移植 Bas通用

解决思路

  1. 确认脚本运行环境是 Bash：Linux、macOS、WSL、Windows 上的 Git Bash/MSYS2，或基于 Bash 的容器镜像；不处理原生 PowerShell。
  2. Windows 上若目标是原生 PowerShell，改用 powershell-master；本技能假设 Bash 运行在 Git Bash、WSL 或类似环境，并处理 MSYS 路径转换问题。
  3. 项目级约定（如工具调用中的 Windows 反斜杠、文档规范）放在 agent body 和 windows-path-master 插件中；本技能只专注 Bash 内容，不重复这些样板。
  4. 脚本开头使用 shebang：#!/usr/bin/env bash。
  5. 脚本开头设置 set -euo pipefail（或分别 set -e、set -u、set -o pipefail）。
  6. 增加 set -E，把 ERR trap 继承到函数中。
  7. 设置 IFS=$'\n\t'，避免按空格意外分词。
  8. 用 readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" 获取脚本目录。
  9. 用 readonly SCRIPT_NAME="$(basename "${BASH_SOURCE[0]}")" 获取脚本名。
  10. 部署前运行 shellcheck your_script.sh。
  11. 生产前在每个目标平台测试。
  12. 按目标选择解释器：需要运行于任何 UNIX sh 时用 #!/bin/sh，不用 [[ ]]、数组、进程替换。
  13. 现代 Linux/macOS 且有 Bash 时用 #!/usr/bin/env bash，优先使用 [[ ]]、数组、正则。
  14. Alpine/最小容器中要么显式安装 bash，要么写 POSIX 兼容的 sh。
  15. 始终引用变量展开：process "$file_path"，不要 process $file_path。
  16. 数组元素要分开处理：files=("file 1.txt" "file 2.txt"); process "${files[@]}"。
  17. 不要用 process "${files[*]}" 把数组元素拼成一个字符串，除非确实需要。
  18. 对每个脚本运行 shellcheck。
  19. 只有带理由注释时才禁用 ShellCheck 警告，例如 # shellcheck disable=SC2086 reason: intentional word splitting。
  20. 查阅 references/best_practices.md 获取完整引用/风格表。
  21. 查阅 references/patterns_antipatterns.md 获取常见陷阱。
  22. Git Bash/MSYS2 中注意 Unix 风格参数会被自动转成 Windows 路径，例如 /foo 变为 C:/Program Files/Git/usr/foo。
  23. 需要某命令参数保持 Unix 路径时，用 MSYS_NO_PATHCONV=1 command /path/that/should/stay/unix。
  24. 需要手动转换路径时用 unix_path=$(cygpath -u "C:\Windows\System32") 和 win_path=$(cygpath -w "/c/Users/username")。
  25. 检测 Git Bash：if [[ "$OSTYPE" == "msys" ]] || [[ "$OSTYPE" == "mingw"* ]]; then ...; fi。
  26. 检测 MSYS2/Git Bash：case "${MSYSTEM:-}" in MINGW64|MINGW32|MSYS) ... ;; esac。
  27. 处理看起来像路径的 flag：command //e //s 用双斜杠抑制转换，或 command -e -s 使用 dash-options。
  28. 查阅 references/windows-git-bash-paths.md 获取 Git Bash + Windows 路径完整说明。
  29. Linux 上利用 GNU coreutils、/proc、systemd 集成；检测用 [[ "$OSTYPE" == "linux-gnu"* ]]。
  30. macOS 上注意 BSD 与 GNU 工具差异：sed -i '' 需要空字符串，date 参数不同，stock macOS 没有 readlink -f。
  31. macOS 上按需选择 GNU 工具：if command -v gsed >/dev/null; then SED=gsed; else SED=sed; fi。
  32. WSL 中按 Linux 处理；Windows 文件系统挂载在 /mnt/c/；检测用 grep -qi microsoft /proc/version。
  33. 容器中 Alpine 只带 /bin/sh（BusyBox）：写 POSIX 兼容脚本或 apk add bash。
  34. 容器 init 场景中 PID 1 必须回收子进程并处理信号。
  35. 检测容器：用 [ -f /.dockerenv ] 或 [ -n "$KUBERNETES_SERVICE_HOST" ]。
  36. 使用可移植平台检测模板 detect_platform()，根据 "$OSTYPE" 返回 linux、macos、windows 或 unknown。
  37. 查阅 references/platform_specifics.md 获取 BSD-vs-GNU coreutils flag、WSL networking、container init patterns 等表格。
  38. 每个函数只做一个关注点；先声明 locals；验证输入；出错返回非零。
  39. 常量用 UPPER_CASE；局部变量用 lower_case；不可变值用 readonly 标记。
  40. 始终检查退出码：if ! cmd、||、traps，或集中的 error_exit helper。
  41. 验证所有外部输入：非空、格式、长度、字符集。
  42. 使用 getopts 或基于 case 的参数解析器；参数错误时打印 usage 并 exit 1。
  43. 使用分级别 logger，并写入 stderr。
  44. 查阅 references/in-depth-patterns.md 获取函数设计、错误处理、输入验证、参数解析、日志的完整模式。
  45. 安全：防止命令注入、路径穿越防护、权限管理、安全临时文件。
  46. 性能：避免 subshell、优先 Bash 内建而不是外部命令、使用进程替换、数组操作。
  47. 测试：BATS 单元测试、集成测试模式、CI/CD 接线。
  48. 调试：set -x、PS4、条件调试 helper、跟踪和 profiling。
  49. 高级模式：安全配置解析、并行处理、信号处理、带退避的重试。
  50. 需要上述主题的规范代码模板时查阅 references/in-depth-patterns.md。
  51. 查阅 references/platform_specifics.md 详细平台差异和 workaround。
  52. 查阅 references/best_practices.md 行业标准和指南。
  53. 查阅 references/patterns_antipatterns.md 常见模式、陷阱及解决方案。
  54. 查阅 references/windows-git-bash-paths.md Git Bash/MSYS 路径翻译参考。
  55. 查阅 references/resources.md 官方文档、风格指南、工具和学习链接。
  56. 成功标准：脚本应通过 shellcheck 且无警告。
  57. 成功标准：以 set -euo pipefail 开头。
  58. 成功标准：引用每个变量展开。
  59. 成功标准：在 -h/--help 时打印 usage。
  60. 成功标准：拆解为可测试函数。
  61. 成功标准：处理空输入、缺失文件、意外参数。
  62. 成功标准：在声称支持的每个目标平台（Linux/macOS/WSL/Git Bash/container）上运行。
  63. 成功标准：符合 Google Shell Style Guide。
  64. 成功标准：退出时清理（trap EXIT）。
  65. 成功标准：逻辑不简单时用 BATS 做单元测试。
  66. 部署前检查清单：shellcheck script.sh。
  67. 部署前检查清单：bash -n script.sh。
  68. 部署前检查清单：bats test/script.bats。
  69. 部署前检查清单：./script.sh --help。
  70. 部署前检查清单：DEBUG=true ./script.sh。
  71. 脚本在其他平台失败时，用 checkbashisms script.sh 暴露非可移植结构。
  72. 脚本在其他平台失败时，用 command -v tool 验证所需工具已安装。
  73. 脚本在其他平台失败时，对比 GNU 和 BSD 命令 flag（如 sed --version）。
  74. ShellCheck 警告：阅读规则解释，例如 shellcheck -W SC2086。
  75. ShellCheck 警告：修复根因；只有带理由注释时才禁用规则。
  76. 交互式可运行但 cron 失败：cron 的 PATH 很小，显式设置 PATH。
  77. 交互式可运行但 cron 失败：使用绝对路径。
  78. 交互式可运行但 cron 失败：重定向 stdout/stderr，例如 ./script.sh >> /tmp/cron.log 2>&1。
  79. 性能问题：用 time 做 profile。
  80. 性能问题：启用 set -x 找慢步骤。
  81. 性能问题：尽可能用 Bash 内建替换外部调用。

适用边界 · 注意事项