Four things found while re-reading the family of scripts around the
logout fix.
Both installers piped curl straight into tar, so a truncated download
half-extracted — and the installer explicitly supports reinstalling over
an existing install, which turned an interrupted download into a tree
mixing old and new files with no error saying so. They now download to a
temp file and verify the archive in a staging dir before writing
anything to the install directory: the ordering update.sh has had since
it was written, for the same reason.
update.sh never removed files deleted upstream. Extracting over the
install dir only adds and overwrites, so a renamed page under docs/ kept
being mounted read-only into every container for the assistant to read,
and a removed command kept being discovered. It now prunes, from the
directories the tarball owns end to end (web, commands, skills, docs),
whatever the already-verified staging copy does not have. Pruning after
the extraction rather than replacing the directory keeps every
intermediate state a complete install. agents/ is deliberately excluded:
dropping in an agent is a documented extension point, so that directory
is not ours alone and pruning it would delete somebody's work.
uninstall.sh fed `docker ps -aq --filter 'name=skald-'` to `docker rm
-f`. Docker's name filter is a regex matched anywhere in the name, not a
prefix, so any unrelated container merely containing "skald-" was
force-removed. Anchored to ^skald-.
uninstall.sh also matched uname's raw Linux/Darwin while its three
siblings normalize to lowercase. It was correct on its own, but being
the odd one out of four copy-paste relatives is precisely how update.sh
acquired its no-op case arms, so it now normalizes like the others.
Finally, the uninstaller reports that lingering is still enabled and how
to turn it off, rather than disabling it: it is a persistent per-user
setting other user services may rely on by now, so taking it back
silently would stop those too.
homes/ directory can contain files owned by other UIDs (root, etc.)
because Docker containers run as different users. Normal rm -rf fails
with Permission denied. Now falls back to sudo rm -rf automatically.
dguiducci