编程与软件工程github.com
在 Bash 中安全做事的办法
Safe ways to do things in bash
2018 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Shellharden 仓库中的一份 bash 安全实践指南，围绕引号、变量展开、通配符、错误处理选项等常见陷阱，给出更稳健的写法。它适合想减少 shell 脚本隐蔽 bug 的人查阅。
为什么经久不衰：bash 仍是大量环境里的默认 shell，而引号、set -e、通配符这些坑多年未变，清单式建议至今可随时查漏补缺。
HN 评论精选
偏好始终使用 "${var}" 以保持一致性和更清晰的 diff。
文章里写道：> 我应该用花括号吗？坏：some_command $arg1 $arg2 $arg3；特别坏（盲目套用不必要的花括号）：some_command ${arg1} ${arg2} ${arg3}；正确：some_command "${arg1}" "${arg2}" "${arg3}"；更好：some_command "$arg1" "$arg2" "$arg3"。……我更喜欢所有变量都用 "${带花括号}" 的形式。它确实稍微啰嗦，但胜在一致；当变量嵌在完整字符串里时，整体引号更少、看起来更舒服，diff 也更干净——把 "${foo}" 改成 "${foo}-bar" 只会产生 "-bar" 的 word-diff。
koolba查看英文原文
From the article: > Should I use curly braces? Bad: some_command $arg1 $arg2 $arg3 Extra bad (cargo culting unnecessary braces): some_command ${arg1} ${arg2} ${arg3} Correct: some_command "${arg1}" "${arg2}" "${arg3}" Better: some_command "$arg1" "$arg2" "$arg3" > In the "extra bad" and "correct" examples, braces compete with quotes under the limits of tolerable verbosity. > Shellharden will rewrite all these variants into the "better" form. I prefer the "${bracey}" form for all variable usage. Yes it's marginally more verbose but it has the advantage of being consistent, easier on the eyes due to less overall quoting when part of full string interpolation[1], and cleaner diffs[2] as converting "${foo}" to "${foo}-bar" only leads to word-diff of "-bar". [1]: "${foo} bar baz" v.s. "$foo"" bar baz" [2]: You are source controlling your shell scripts right?
用 Python 替代 shell 脚本更稳健、可维护。
我最近干脆不写 shell 脚本了，改用 Python。它的类型系统虽然不算最先进，但仍远胜字符串类型的 bash；库很好，很多事只用标准库就能做；脚本也快得多，因为不必为每个小字符串操作启动子进程。需要调用外部进程时，subprocess 模块比 set -e 稳健得多。说真的，能避免就别写 shell 脚本，用真正的编程语言。
pwdisswordfish8查看英文原文
I've recently taken to not bothering with shell scripts at all. I just use Python instead. The type system, while it's by no means state of the art, is still miles ahead of the stringly-typed bash. The libraries are excellent; much can be done with the standard library alone. The scripts are much faster (even though the language isn't particularly tuned for performance), since I don't need to spawn a subprocess for each little string manipulation task. And if I ever need to ‘shell out’ to an external process, there's always the subprocess module that is much more robust than ‘set -e’ ever was. Seriously, if you can avoid it, just don't write shell scripts at all. Use a real programming language instead.
推荐 ShellCheck、提交钩子和 Google 风格指南作为配套工具。
如果你对编写安全的 shell 脚本感兴趣，看看 shellcheck：https://github.com/koalaman/shellcheck 。我还写了一个 git hook，在 git commit 时运行检查：https://github.com/alblue/scripts/blob/main/shellcheck-pre-commit 。另外也推荐 Google 的 shell 脚本风格指南：https://google.github.io/styleguide/shellguide.html 。
alblue查看英文原文
If you’re interested in writing safe shell scripts then check out shellcheck: https://github.com/koalaman/shellcheck If you’re interested I’ve written a git hook for it that runs a check when you git commit: https://github.com/alblue/scripts/blob/main/shellcheck-pre-commit You should also check out her Google shell script style guide: https://google.github.io/styleguide/shellguide.html
nullglob 和 errexit 有副作用，显式错误处理更可靠。
我几乎同意这份指南的所有内容，但有几条建议在解决一些问题的同时会制造新问题。nullglob 选项能让 for f in *.txt 在没有匹配文件时表现正常，却会让 grep somepattern *.txt 这类命令改变行为：grep 等命令在没有输入文件时会从标准输入读到 EOF；交互运行时可能莫名挂起，输入被重定向时又会偷走本来给其他命令的输入。我认为这比它解决的问题更严重。errexit（set -e）也可能在该退出时没退出、在不希望时退出；用 || true 抑制意外退出并不总是明显，而且不同 bash 版本还不一致。我更愿意显式处理错误，比如 commandThatMightFail || { echo "Aaaargh" >&2; exit 1; }。
gdavisson查看英文原文
I agree with almost everything in this guide, but it has a couple of recommendations that create new problems (while solving others): The nullglob option ('shopt -s nullglob') makes things like 'for f in .txt' work right when there are no matching files, but make other commands like 'grep somepattern .txt' change their behavior in ways that can cause serious trouble. grep (and many other commands), given no files as input, will read from standard input (up to the EOF); if it's running interactively and input hasn't been redirected, this causes the script to hang for no discernible reason. If input has been redirected, it steals input that was presumably meant to be read by some other command. In my opinion, the problems this causes are more serious than what it solves. The errexit option ('set -e' or 'shopt -s errexit') can both fail to exit when you expect/want it to (several such situations are described in the guide) and also exit when you don't expect/want it to. The guide mentions suppressing unexpected exits with '|| true', but it's not always obvious when this is needed, and it's not even consistent between versions of bash. There's a good parable about this (and some examples) at http://mywiki.wooledge.org/BashFAQ/105 I really don't like trying to predict and work around unpredictable features like this; I'd much rather deal with explicit error handling, like 'commandThatMightFail || { echo "Aaaargh" >&2; exit 1; }'
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选