v0.53.0 — the pit stops suspending itself

The pit stops suspending itself

v0.52.0 taught pit commands to load your shell's rc file so /alias could name a shell alias. It worked, and it also brought job control along with it — which could take the pit's terminal away and not give it back:

mosh ▸ /gh-prs-merge-all
· zsh -ic gh-prs-merge-all --apply
────────────────────────────────────────
Summary: ready=1 readied=0 merged=1 skipped=0 failed=0
────────────────────────────────────────
· shell exited (code 0). back in the pit.
[1]  + 3034615 suspended (tty output)  moshcode

An interactive shell makes itself a process group leader and claims the terminal, then on exit hands it back to what it believes the shell before it was. The pit is not a shell and does not play that game, so the terminal could be left belonging to a process group that had already exited — and the pit's very next write took SIGTTOU.

Measured under a real terminal: zsh -c has job control off and cannot see your aliases, zsh -ic sees them and has job control on, and zsh +m -ic sees them with job control off. So pit commands now run with +m.

Nothing is given up for it. Job control is for managing several jobs at a prompt, and this shell runs one command and exits; +m also restores exactly the signal behaviour of the plain -c that v0.51.0 used, where the command shared the pit's process group.

bash is left alone on purpose: an interactive bash turns job control back on regardless of +m, so passing it there would advertise a protection that is not real.

If you are on 0.52.0, this is the release that supersedes it.

The root password is asked for before the work, not partway through

Some installers escalate on their own, partway through their own work — tailscale's goes through your distro's package manager, so it calls for a password after it has already spent time refreshing package lists. That is tolerable when it is the only thing running. Inside moshcode update it was not, because that walks a plan: moshcode itself, then every installed engine, then every tool. On a machine with tailscale installed the prompt landed at step 17 of 18 — long after anyone was still watching, and sometimes after the escalation helper's own timeout had already failed the step.

MoshCode now asks first, before the first hand-off. The credential is cached against the terminal that every installer inherits, so the escalation they do later finds it already there and never asks.

It stays quiet unless it has something to ask. Nothing happens when no step in the plan needs root — the ordinary moshcode update never prompts — nor when a credential is already cached or the rule is NOPASSWD, nor when there is no terminal to type into, nor when there is no sudo/doas on the box, nor when you are already root. macOS is spared too: there the tailscale script delegates to the App Store, which does its own authorisation.

A declined prompt is never fatal. The installer prompts for itself if it turns out to need to, which is exactly the old behaviour — being unable to ask early is a missed convenience, not a reason to refuse to install.

Full changelog: v0.52.0...v0.53.0