mirror of
https://github.com/awizemann/scarf.git
synced 2026-05-10 10:36:35 +00:00
Alan Wizemann
587c6c36c8
@cmalpass's April 25 follow-up on #19: diagnostics reported "sqlite3 not installed or on system PATH" while sqlite3 was actually installed and Hermes was using it fine. Same false-negative class the `hermes` probe pre-fix had — a bare `command -v sqlite3` in the non-login SSH shell misses installs at /opt/homebrew/bin or /usr/local/bin when the user's PATH export lives in .zprofile (the typical Homebrew setup). The hermes probe was upgraded to source rc files + walk a candidate list; sqlite3 wasn't. Mirror the same pattern: - Move the sqlite3 detection AFTER the rc-source loop so the login PATH is in scope. - Add a standard-location fallback list: /usr/bin/sqlite3, /usr/local/bin/sqlite3, /opt/homebrew/bin/sqlite3, /opt/local/bin/sqlite3. - Use the resolved sqlite3 binary explicitly in the sqlite3CanOpenStateDB probe so it doesn't re-fail-by-PATH when the binary is at e.g. /opt/homebrew/bin. Falls back to bare `sqlite3` so the FAIL detail line still carries the real error. Hermes non-login probe stays as-is — that semantic ("is hermes on the un-enriched PATH?") is meaningful and we don't want to muddle it. Failure-hint copy on sqlite3Installed updated to spell out the new fallback behavior so users who still see FAIL get accurate guidance (install via package manager, OR symlink an existing binary into a location the probe checks). Closes the third and last open layer of #19. Layer 1 (104-byte ControlMaster path) was fixed in v2.0.2; layer 2 (pill / diagnostics disagreement) was fixed in v2.5.1 (#44). Ships in v2.5.2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>