try：用 overlayfs 和命名空间，在提交前看清命令会改什么

它解决的是什么问题

在 Linux 上安装软件或运行配置脚本时，你往往无法预知命令会改动哪些文件。pip 可能写入 site-packages，curl 管道脚本可能修改 .bashrc，而你只能在事后发现。try 把这个问题拆成两步：先运行命令，再决定是否把改动合并到真实系统。它面向的是那些需要反复尝试安装或配置，又不希望每次都在系统里留下痕迹的人。文档明确说 try 是 semisolate，不是 sandbox，网络调用完全放行，所以它解决的是「可回滚」的问题，不是「安全隔离」的问题。

底层机制：unshare 加 overlayfs

try 的核心依赖是 Linux 的 unshare 系统调用和 overlayfs 联合文件系统。unshare 让命令运行在独立的命名空间里，overlayfs 则把改动写入一个临时 upperdir，而不是直接写到真实文件系统。命令执行后，try 会展示一份改动清单，询问你是否提交。如果你选择不提交，临时目录被丢弃，系统保持原样。这种设计和 Docker 的镜像分层思路类似，但 try 面向的是单条命令，而不是容器生命周期。文档还提到，在嵌套挂载场景下 overlayfs 可能无法工作，这时 try 会尝试使用 mergerfs 或 unionfs，并允许用 -U 参数手动指定路径。

安装方式与依赖

最简单的安装方式是直接下载 try 脚本，放到 PATH 里即可使用，但文档称之为「quick and janky」，因为没有文档和辅助工具。正式安装需要从源码构建：git clone 仓库后，运行 autoconf、./configure、make，然后 sudo make install。注意仓库本身不包含 configure 和 manpage，它们由 autoconf 和 pandoc 生成，所以从 GitHub 克隆时需要安装这两个依赖。也可以从 release 页面下载 try-latest.tgz 源码包，里面已经包含了 configure 和 manpage，构建步骤更少。Arch Linux 用户可以通过 AUR 安装，NixOS 用户可以用 nix-shell -p try。依赖的 Debian 包包括 attr，用于 getfattr。

实际用法：从 try 到 commit

try 的典型用法是直接包裹一条命令，例如 try pip3 install libdash。执行结束后，try 会列出检测到的文件改动，并提示是否提交。如果你不想立即决定，可以用 try -n 让 try 只打印 overlay 目录路径而不提交，这样之后可以手动检查改动。你也可以用 try -N 指定一个已有的 overlay 目录，比如 mkdir rustup-sandbox && try -N rustup-sandbox "curl https://sh.rustup.rs | sh"，然后通过 try summary 查看该目录下的改动摘要，最后用 try commit 把改动合并到真实系统。此外还有 try explore 命令，可以让你在 try 环境中打开一个 shell，适合交互式调试。

一个真实的失败模式：嵌套挂载

文档提到，在嵌套挂载的环境里，overlayfs 可能无法正常工作。比如在容器内或某些虚拟化环境中运行 try，overlayfs 的上层挂载可能会失败。try 会尝试自动检测并使用 mergerfs 或 unionfs 作为替代，但这不是万能的。如果这两个工具都没有安装，try 可能直接报错。另一个限制是内核版本要求：Linux 5.11 或更高，因为 overlayfs 在用户命名空间中的支持是在这个版本引入的。如果你运行的是旧内核，try 根本无法工作。这意味着 try 并不适合所有 Linux 环境，尤其是那些长期不更新的服务器。

与沙箱工具的差异

try 明确把自己定位为 semisolate，而不是 sandbox。这意味着它不会限制网络访问，也不会阻止命令读取或写入系统敏感区域。相比之下，bubblewrap 或 firejail 这类工具会通过 seccomp、网络命名空间和权限限制来隔离进程。try 的目标不是防止恶意命令，而是让你在命令执行后、提交前有机会审查改动。如果你需要的是安全隔离，try 是错误的选择。但如果你只是想避免安装脚本意外覆盖配置文件，try 的交互式提交流程比手动备份文件要直观得多。文档还强调，不要用 try 执行你不信任的命令，这正好说明了它的边界。

维护成本与许可证

try 的维护成本取决于你如何安装。直接下载脚本的方式几乎没有维护负担，但缺少辅助工具和文档。从源码构建则需要定期拉取更新并重新编译，好在构建步骤简单，只有 autoconf 和 make。项目采用 MIT 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。需要注意的是，try 依赖的系统组件（unshare、overlayfs）由内核提供，所以内核升级可能会影响 try 的行为，但目前没有证据表明存在兼容性问题。另外，try 的测试套件需要 bash、expect 和 curl，如果你打算自行修改代码，这些是必要的测试依赖。

编辑结论

try 适合那些经常运行安装脚本、包管理器或配置命令，并且希望在这些命令真正改动系统之前，先看清楚它们会碰哪些文件的 Linux 用户。它不适合作为安全沙箱，因为网络访问不受限制，文档也明确警告不要用它执行不信任的命令。在采用之前，你需要确认内核版本至少为 Linux 5.11，否则 overlayfs 在用户命名空间里无法工作。如果你的发行版是 Ubuntu 20.04 或 Debian 12 等已测试的系统，安装和运行会比较顺利。对于需要严格隔离的场景，应该考虑使用 bubblewrap 或 firejail 这类真正的沙箱，而不是 try。最终判断是：try 的价值在于它把 overlayfs 和命名空间封装成了一个简单的 try 命令，让你在提交前有机会反悔，但它不会替你判断命令是否安全。

官方来源

1. Official README
2. Project repository
3. Release notes