open

open is a small, focused Rust crate that opens a path or URL using whatever program the operating system has configured for it — the Rust equivalent of running open on macOS, start on Windows, or xdg-open/gio open/gnome-open/kde-open on Linux (with WSL handled via PowerShell fallback). A single open::that("https://rust-lang.org") call abstracts away all of that platform detection.

Beyond the default-opener case, open::with(path, app) lets callers specify a particular application to launch the target with, and the crate also ships a small standalone binary that behaves like a generic opener from the command line. It’s a common dependency in CLI tools and desktop apps that need to hand off a file or link to the user’s environment (e.g. opening a generated report, a login page, or a config file) without shelling out to platform-specific commands by hand.

What You Get

• open::that(path) to launch a path or URL with the OS-configured default program
• open::with(path, app) to open a target with a specific application instead of the default
• Platform-specific backends for macOS, Windows, Unix/Linux, WSL, Redox, iOS, and Haiku, selected automatically at compile time
• An optional standalone open binary that behaves like a generic cross-platform opener from the shell
• A Windows-only insecure feature flag for restoring the legacy cmd /c start launcher when needed, clearly documented as unsafe for untrusted input

Common Use Cases

• CLI tools opening a generated report, dashboard, or docs page in the user’s browser after a command finishes
• Desktop or dev-tool apps launching a config file, log file, or project folder in the user’s preferred editor/file manager
• Onboarding flows that open a login or OAuth URL in the default browser
• Build tools or scaffolding CLIs that open the newly created project in an IDE

Under The Hood

Architecture — src/lib.rs (440 lines) defines the public that/with API and dispatches to one of several platform-specific modules selected via cfg attributes: macos.rs, windows.rs (479 lines, the largest, handling both command-based and ShellExecuteW-based launching), unix.rs, wsl.rs (164 lines, detecting WSL and falling back through PowerShell then native Linux openers), plus small stubs for redox.rs, haiku.rs, and ios.rs. A separate main.rs builds the optional CLI binary on top of the same library functions.

Tech Stack — Pure Rust, edition 2018, with minimal platform-conditional dependencies: libc on Unix, is-wsl for WSL detection, and an optional dunce dependency gated behind the shellexecute-on-windows feature. No async runtime or heavy dependency tree — the crate is intentionally lightweight.

Code Quality — Test coverage is thin and platform-specific (a handful of #[test] functions in windows.rs, wsl.rs, unix.rs, and macos.rs), which is a reasonable trade-off given how much of this crate’s behavior is inherently about shelling out to OS commands that are hard to unit test portably; cross-platform CI (GitHub Actions cross-platform-testing workflow) substitutes for deeper local test coverage. Code is compact, consistently formatted (rustfmt.toml present), and the insecure feature is documented with an explicit security warning about untrusted input.

API Design — The API surface is intentionally minimal — two functions (that, with) cover the vast majority of use cases — which makes onboarding nearly instant; the README leads with the exact one-liner most users need. The main design decision exposed to users is the insecure and shellexecute-on-windows feature flags, which is a sensible way to keep the safe default while still allowing opt-in legacy/alternate behavior on Windows.