v0.1.4

prevent orphaned tmux -C subprocesses on abnormal consumer exit

previously the control transport spawned a long-lived tmux -C attach-session child that was reliably killed only by an explicit (*Tmux).Close(). a consumer that exited without Close — crash, signal, or a short-lived subcommand — orphaned the child, leaving it attached to the tmux server until the server died. in practice this showed up as dozens of accumulated orphans saturating the single-threaded tmux server.

fixes

• add build-tagged sysProcAttr() helpers applied to the spawned command: linux sets Pdeathsig: SIGKILL (the kernel reaps the child on parent death) plus Setpgid; darwin/bsd set Setpgid only, since there is no pdeathsig equivalent; non-unix returns nil (440c9d0)
• derive an internal cancelable lifetime context in New, cancelled by Close() and on child exit, giving a second CommandContext-based kill path independent of Process.Kill (440c9d0)

additions

• expose NewTmuxContext(ctx, socket, ...) so consumers can bind a client's lifetime to e.g. signal.NotifyContext (440c9d0)

notes

• calling Close() remains mandatory on macOS/bsd, where there is no parent-death signal to fall back on

tests

• platform helper coverage (Setpgid everywhere, Pdeathsig on linux)
• that New wires SysProcAttr onto the command
• that NewTmuxContext threads its context through to the dialer

upgrading

go get github.com/atomicstack/gotmuxcc@v0.1.4