diff options
| author | Danilo M. <danix@danix.xyz> | 2026-09-12 10:05:56 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-09-12 10:05:56 +0200 |
| commit | 15367430ddafd45c59310364234fa3ceefee3844 (patch) | |
| tree | 558954121cf13ce1dc7b093f977b243d5e45311e /CLAUDE.md | |
| parent | 9cf3aaea8cc356a87321f3a8df96fdf68ff921b0 (diff) | |
| download | quickshell-15367430ddafd45c59310364234fa3ceefee3844.tar.gz quickshell-15367430ddafd45c59310364234fa3ceefee3844.zip | |
docs: correct the notmuch malformed-query claim
The previous commit, the spec and the plan all said notmuch exits 0 on a
malformed query while printing something that is not a count, and that
validating the output as an integer therefore catches it. Measured properly,
that is wrong in a way worth recording, because the truth is worse.
notmuch fails two different ways. A rejected query prints nothing and exits 1:
`notmuch count 'tag:unread and ('`. A query Xapian merely misparses returns a
plausible wrong number and exits 0: `notmuch count 'tag:unread and (('` gives
41, and `'tag:unread and tag:'` gives 3. The second is undetectable by any
check on the output, which is why the original claim was not just imprecise
but inverted: the case it described as caught is the case nothing can catch.
The integer validation still earns its place, on the first failure mode, where
empty output would otherwise render as an empty inbox. The real defence
against the second is that QUERY is a fixed string and is never built from
anything, which the comment now says.
The earlier measurement that produced the wrong claim read 40 as mangled
output when it was a successful parse answering a different question.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WWL8JYHu7yhAdtx5pU9PMU
Diffstat (limited to 'CLAUDE.md')
0 files changed, 0 insertions, 0 deletions
