dsh-open-path

In a terminal-driven workflow, every file or link you want to open forces you to jump out to a browser or drag back to a file manager, breaking your cadence. dsh-open-path folds that into a single /open command: pass a path and the file opens, pass a URL and it goes to the default handler, pass a bare domain and the scheme is filled in, pass a keyword and it fuzzy-searches your workspace in a CJK- and case-insensitive, Unicode-normalised way. One hit opens immediately, several hits surface a scrollable candidate panel, zero hits produce an explicit error - never a silent swallow.

Cross-platform reliability is the other pillar. Windows rides Shell.Application COM with a cmd start fallback, macOS delegates to open, Linux walks the xdg-open, gio open, kde-open5 chain in order, and WSL bridges straight to the Windows-side handler. Any launcher that fails to spawn or exits non-zero quickly triggers the next candidate; only when the whole chain is exhausted does the command report an explicit error listing every launcher it tried. The success receipt is deliberately two-tiered: a confirmed open requires exit zero inside the grace window, while a still-alive process at window expiry is labelled as launched but unconfirmed. A timeout is never dressed up as success.

Who is it for? Developers and operators who live inside the dsh-TUI terminal surface and want one command to reach the file manager or browser without leaving the session. It produces no model messages, consumes no tokens, and touches no KV cache - purely a UI-layer shortcut that takes effect on the next restart.