try: Run Commands in a Linux Semisolate Before You Commit to the Changes

What try Solves That a Dry Run Cannot

Most package managers and installers do not offer a dry-run mode that shows every file they would create or modify. try fills that gap by running the command in an isolated overlay and then asking whether you want to commit the changes. The README describes it as a higher-order command, like xargs or nohup, meaning it wraps whatever command you give it. The target user is someone who runs installers such as pip or curl-based scripts and wants a visible diff of the effects before those effects become permanent. It is not for executing untrusted code; the documentation calls try a semisolate, not a sandbox, and warns that network calls are all allowed. If you already trust the command but want to inspect its footprint, try gives you a concrete way to do that.

The Mechanism: Namespaces, Overlayfs, and a Commit Prompt

Under the hood, try uses Linux namespaces via unshare and the overlayfs union filesystem. The command runs inside a new mount and user namespace, and all file writes go to an upperdir on top of a lowerdir that mirrors your live filesystem. When the command finishes, try presents a prompt asking if you want to commit the changes. If you commit, the upperdir contents are merged into the live filesystem. If you decline, the overlay is discarded. The README notes that overlayfs needs kernel 5.11 or higher for it to work in a user namespace, so older kernels will not work. The design is deliberately lightweight: no daemon, no image, just a shell script that orchestrates the kernel features.

Installation Paths: From a Single Script to a Full Build

The quickest install is to grab the single try script and put it in your PATH. That version lacks documentation and support utilities, but the README says it should work. For a fuller install, clone the repository, run autoconf, then ./configure, make, and sudo make install. This gives you the manpage and faster support utilities. A source distribution from the release page includes the configure script and manpage already generated, so you skip autoconf. There are also packages for Arch via the AUR and for NixOS via nixpkgs. The dependencies are attr for getfattr, and pandoc plus autoconf only if building from a clone. If overlayfs fails on nested mounts, you can supply mergerfs or unionfs with the -U flag, and try autodetects them otherwise.

Working with Overlay Directories: -n, -N, and Manual Inspection

By default try asks for a commit at the end. If you want to defer that decision, run try -n, which prints the overlay directory path and does not commit. You can also specify your own overlay directory with -N, as in try -N rustup-sandbox "curl https://sh.rustup.rs | sh". That creates a directory containing temproot, upperdir, and workdir. The upperdir holds the actual file changes; the README shows a rustup install producing 1.2G of changes in that directory. You can inspect those changes with try summary rustup-sandbox/, which lists modified or added files. Later you can commit with try commit rustup-sandbox. There is also try explore to open a shell inside an existing overlay. This workflow is useful for auditing an installer before you let it touch your home directory.

Real Limitation: It Is a Semisolate, Not a Security Boundary

The most important limitation is stated explicitly in the README: try should not be used to execute commands that you do not already trust. Network calls are allowed, so a malicious script can exfiltrate data or download more code. The isolation is about file system effects, not process or network containment. Also, overlayfs may not work on nested mounts, and the README notes you may need mergerfs or unionfs as a fallback. The kernel version requirement of 5.11 or higher is a hard gate; on older distributions try will not function. For a user who wants to test an untrusted script, try is the wrong tool. The semisolate design is a trade-off: it is lighter than a full sandbox, but it does not protect you from the command's network activity.

The Alternative: Containers or Native Dry Runs

If you need stronger isolation, a container runtime such as Docker or Podman gives you a real sandbox with network control and process isolation. Those tools are heavier: they require daemons, images, and more setup. try's approach is different: it uses only kernel namespaces and overlayfs, so it does not need a separate image. For simple cases, your package manager might already have a dry-run flag, like apt --dry-run or pip's --dry-run, which shows changes without applying them. Those flags are faster and simpler, but they only work for that specific tool. try works for any command, which is its main advantage. The trade-off is that you get a semisolate, not a true sandbox, so choose based on whether you trust the command.

Maintenance and License: What You Are Adopting

The project is written in Shell and licensed under MIT, so there are no restrictive license implications for incorporating it into your own scripts. The repository has had releases since 2023, with a latest tarball dated October 2026 and a paper at OSDI'26, which suggests active development. The build process depends on autoconf and pandoc only for maintainers; end users can grab the prebuilt script. The test suite requires bash, expect, and curl, and you can run it with scripts/run_tests.sh or make test after building. The maintenance cost is low for a shell script, but you should track kernel updates: a future kernel change could break overlayfs behavior in user namespaces. You are responsible for updating the script when new releases appear.

Editorial conclusion

Adopt try if you routinely run package installers or scripts that modify many files and you want a quick, inspectable rollback point without a full VM or container. Do not use it as a sandbox: network calls are allowed, and the README explicitly says it is for commands you already trust. Before relying on it, verify your kernel is at least 5.11, check that overlayfs works in your user namespace, and test with your package manager or installer, since some may fail on a semisolate. If you need stronger isolation, use a container runtime or a dedicated sandbox; if you just want a dry run, check whether your tool has a native --dry-run flag.

Frequently asked questions

Official sources

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