aboutsummaryrefslogtreecommitdiffstats
path: root/vm-manager/Virsh.qml
diff options
context:
space:
mode:
authorDanilo M. <danix@danix.xyz>2026-09-12 10:05:56 +0200
committerDanilo M. <danix@danix.xyz>2026-09-12 10:05:56 +0200
commit15367430ddafd45c59310364234fa3ceefee3844 (patch)
tree558954121cf13ce1dc7b093f977b243d5e45311e /vm-manager/Virsh.qml
parent9cf3aaea8cc356a87321f3a8df96fdf68ff921b0 (diff)
downloadquickshell-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 'vm-manager/Virsh.qml')
0 files changed, 0 insertions, 0 deletions