Commit Graph
2 Commits
Author SHA1 Message Date
jcoffey-dev 317fdac938 Make the prune removal threshold actually reachable
The removal-count guard was skipped whenever --yes was set:

    if [[ "${ASSUME_YES}" != "yes" && "${remv_count}" -gt ... ]]

and prune refuses to run *without* --yes. So inside prune -- the only
command that removes anything -- the first condition was always false
and the threshold could never fire. It fired only in plan, which changes
nothing. The guard was live exactly where it did not matter and dead
where it did.

The check is now unconditional, with --max-removals N as the explicit
override, so raising the limit is a separate decision from not wanting
to be prompted. The critical-package check was already unconditional and
is unchanged.

Verified with --yes set and the default limit of 75: an ordinary purge
passes, 90 removals aborts, and a critical package aborts.

Also applies the same startup fix as the converter -- mkdir and the tee
redirection ran at file scope, before argument parsing, so --help and a
mistyped flag failed with a raw mkdir error rather than printing usage.
2026-08-22 22:42:46 -07:00
LINUXexpert.org 5f75b305a7 Add ubuntu-desktop-prune.sh script for cleanup 2026-01-26 23:01:05 -07:00