dure 0.2.3

Detachable Windows console sessions that outlive the terminal
docs.rs failed to build dure-0.2.3
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Visit the last successful build: dure-0.2.1

dure

Detachable Windows console sessions that outlive the terminal.

dure starts an interactive console process under a per-app supervisor, so the session keeps running after the terminal that launched it goes away — a closed window, a dropped SSH connection, or a killed foreground process. A later terminal reattaches to that same session.

dure runs only on Windows. Other targets build, so the workspace stays buildable everywhere, but the resulting binary does nothing except report that the platform is unsupported.

Install

cargo binstall dure

This downloads a prebuilt binary for x86_64-pc-windows-msvc and aarch64-pc-windows-msvc. Every other target, Windows or not, transparently falls back to a source build — and off Windows that build produces only the unsupported-platform refusal, so there is nothing to install there.

Start sessions from the installed dure.exe, not through a wrapper such as cargo run. Wrappers of that kind confine what they launch to a Windows job object that forbids breakaway and is killed when the wrapper exits, so the supervisor could not outlive them; dure run refuses such a launcher outright rather than starting a session that would die with it. Ordinary shells, including the one an SSH session provides, are fine.

Usage

dure [--verbose] run -- <command> [args...]
dure [--verbose] resume [<id>]
dure [--verbose] list
dure [--verbose] kill <id>

run always starts a new session in the current directory and attaches immediately; it never reconnects to an existing one. The command is executed directly rather than through a shell, and it inherits the working directory and environment of the dure run process.

resume attaches to a live session. Without an id it auto-detects: a single live session launched from the current directory is taken, and anything else prints the session list and asks which id to take. list is where those ids come from.

kill <id> abruptly terminates the session's supervisor; the app and its ordinary descendants die with it.

Closing the foreground dure process detaches — the supervisor and app keep running. A new attach displaces any older client, which is also how a wedged client is taken over. Reattaching does not replay what the app printed earlier: the new client starts on an empty screen and then sees live output.

--verbose explains on stderr what a command inspected and decided — where the session store is, which records were read, why each was judged live or dead, and why resume chose a session or fell through to the list. Reach for it when session selection or liveness does not go the way you expected.

A session across two terminals

> dure run -- pwsh.exe
session 1
...work in the shell, then close the terminal window...

The app keeps running. From a new terminal:

> dure list
ID  ATTACHED  SUPERVISOR PID  AGE  LAUNCH DIRECTORY  COMMAND
1   no        12345           4m   C:\work           pwsh.exe

> dure resume

resume finds session 1 because it was launched from C:\work; from anywhere else, name it explicitly with dure resume 1. When the work is done, exit the app normally, or discard the session from another terminal with dure kill 1.