install: replace blanket --yes with explicit --yes-sudo and --yes-delete-stale; no-TTY defaults to decline #204

New issue

Closed

opened 2026-07-17 15:10:00 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-17 15:10:00 +00:00

(Migrated from codeberg.org)

No TTY should mean "cannot consent", not "consents to everything". The dangerous steps are the ones that touch files outside the invoking user's own directories.

Proposal (decided): replace the blanket --yes with one explicit flag per consent. install has exactly two consent prompts, so:

--yes-sudo: consent to the privileged copy via sudo.
--yes-delete-stale: consent to deleting stale madtea copies found outside the destination (the PATH-shadowing cleanup).
--yes itself is removed - it was added by #162 and has not shipped in a release, so there is no compatibility surface to keep.
When stdin is not a TTY and a consent flag was not given, that step takes its decline path: no sudo (per-user ~/.local/bin fallback), no stale-copy deletion; the output names the flag that opts back in.
Interactive TTY runs keep the #162 step-by-step confirmations unchanged.

Acceptance criteria:

No-TTY run with no flags: exit success, binary lands in ~/.local/bin, no sudo invoked, no files deleted outside the chosen destination; output names --yes-sudo / --yes-delete-stale as the opt-ins.
No-TTY run with both flags: today's auto-confirmed behavior (sudo copy + stale deletion) preserved; each flag also works on its own and only unlocks its own step.
TTY behavior unchanged; --yes is gone from help and docs.
docs/COMPARISON.md install row and docs/reference/cli-setup.md updated to the two flags.

Follow-up to #162. The narrated plan prints "Mode: non-interactive (--yes or no TTY); steps run without prompting" - a run with no TTY gets the same auto-confirm as an explicit --yes. On a host with passwordless sudo that makes an accidental scripted invocation fully silent: it escalates, replaces /usr/local/bin/madtea, and the stale-binary sweep deletes other copies, all before anyone sees a prompt. I hit exactly this: a scripted run replaced a production install and swept a go-install copy with zero interaction. No TTY should mean "cannot consent", not "consents to everything". The dangerous steps are the ones that touch files outside the invoking user's own directories. Proposal (decided): replace the blanket --yes with one explicit flag per consent. install has exactly two consent prompts, so: - --yes-sudo: consent to the privileged copy via sudo. - --yes-delete-stale: consent to deleting stale madtea copies found outside the destination (the PATH-shadowing cleanup). - --yes itself is removed - it was added by #162 and has not shipped in a release, so there is no compatibility surface to keep. - When stdin is not a TTY and a consent flag was not given, that step takes its decline path: no sudo (per-user ~/.local/bin fallback), no stale-copy deletion; the output names the flag that opts back in. - Interactive TTY runs keep the #162 step-by-step confirmations unchanged. Acceptance criteria: - No-TTY run with no flags: exit success, binary lands in ~/.local/bin, no sudo invoked, no files deleted outside the chosen destination; output names --yes-sudo / --yes-delete-stale as the opt-ins. - No-TTY run with both flags: today's auto-confirmed behavior (sudo copy + stale deletion) preserved; each flag also works on its own and only unlocks its own step. - TTY behavior unchanged; --yes is gone from help and docs. - docs/COMPARISON.md install row and docs/reference/cli-setup.md updated to the two flags.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#204

No description provided.

Rows
Columns