[rob-archastro]

Review on ArchCode

Problem and author intent

test_interrupt_at_a_prompt_restores_the_terminal in scripts/test-installer-prompts.py is the only failing job in this repo's last six failed Installer Smoke Test runs: three on main (10-19 19:41Z, 10-20 02:24Z, 15:36Z) and three on PR branches, always Unix Installer (macos-latest, zsh) with "installer did not exit".

It is a real installer bug, not just a bad test:

user presses Ctrl-C at an arrow-key menu
  → install.sh is blocked in `read -rsn1 key </dev/tty` with `trap 'exit 130' INT`
  → bash 3.2 (macOS /bin/bash) restarts the interrupted read and defers the trap until it returns
  → the installer waits for another key instead of exiting 130

Whether the test hangs depends on whether Ctrl-C lands during read or during the menu redraw. Locally on macOS with /bin/bash 3.2 it failed 5 runs out of 6.

What changed

install.sh: a read_key helper reads one key with a one-second timeout in a loop. On a timeout (status > 128) it reads again, which gives bash 3.2 a point to run the INT trap. End of input still reads as Enter, as before. The arrow-key menu uses it; the escape-sequence read -rsn2 -t 1 already had a timeout.

Unchanged: the plain-terminal numbered prompt (TERM=dumb) still uses a line read with the same latent behavior. No test covers it, and a timeout on a line read risks dropping partly typed input, so it is left for a follow-up.

Risk

Low. One prompt-input helper. Keys, arrows, digits and Enter behave the same; the only difference is that an idle menu wakes once a second.

Testing

• scripts/test-installer-prompts.py (the test that CI runs on every installer platform):
  • test_interrupt_at_a_prompt_restores_the_terminal with macOS /bin/bash 3.2: 10/10, up from 1/6 before the fix;
  • full suite (12 tests) with macOS bash 3.2: pass;
  • full suite in a Debian container with bash 5.2: pass.
• CI: Installer Smoke Test on this PR.

🤖 Generated with Claude Code