Fabian Hamm
38cc170491
`zq.py` hardcoded one absolute path, and it pointed inside `xenia-rs` -- a repository CONSOLIDATION.md archives in Phase 5 and drops in Phase 7. It resolved on exactly one machine, and on that machine it was days from becoming a `duckdb` exception about a missing file, with nothing saying why. Resolution order is now `$SYLPH_XEXDB`, else `<repo root>/sylpheed.db`, else a refusal that names both. The repo-root path is taken relative to this script, not the caller's cwd, because zq.py is run from wherever the investigation is. No fallback beyond that, on purpose. The database is a build artefact of a few hundred MB and is not tracked, so there is nothing to fall back *to*; a default that silently resolves to the wrong database is worse than no default. That is issue #16's lesson, which was about exactly this shape in the test suite. Both failure paths say what to do and exit 1: $ zq.py fn 82000000 # nothing set, nothing at the repo root no database found. looked for: /…/Sylpheed/sylpheed.db set $SYLPH_XEXDB to an existing one, or build it with: sylph-xexdb dis <xex|iso> --db sylpheed.db --analyze sql $ SYLPH_XEXDB=/nope/missing.db zq.py fn 82000000 $SYLPH_XEXDB is set but is not a file: /nope/missing.db Also fixes the regeneration hint, which still named `xenia-rs dis` -- the retired binary. It is `sylph-xexdb dis`. Connecting is skipped when there is no subcommand, so `zq.py` still prints its usage on a machine that has no database yet. Verified: usage with no db (rc 0); missing db (rc 1); `$SYLPH_XEXDB` set to a non-file (rc 1); and `$SYLPH_XEXDB` pointed at a real 336 MB database, where `imp Rtl` returns its 1,280 `RtlLeaveCriticalSection` call sites. That database turns out to have been generated from the uncommitted tree this branch ports: it carries `import_address`, `import_role` and all 16 foreign keys -- an independent confirmation of the schema the golden test now locks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 KiB
Executable File
16 KiB
Executable File