fix(803,664): round 10 — a raw docstring escaped as if it were not one

Eighth cold review: MERGEABLE, one cosmetic nit, nothing else. It re-derived the bash-exactness table itself, ran an 80k-input randomised differential (the predecessor loses 27 live `jq -e` sightings, this loses 0), and confirmed round 9 touches one test-only file and leaves the shipped CI behaviour untouched. The nit: my round-9 prose went into `_fold_continuations`' `r"""` docstring escaped as though it were an ordinary string, so it rendered `ok=y\\` and `\\bjq\\b` — the latter naming a DIFFERENT regex than the `\bjq\b` the code uses. Small, and exactly the class this branch exists to remove: a claim that does not describe the code. Corrected, and verified by printing `__doc__` rather than by reading the source, since the source is precisely what misled here. No code change. Verification: 1224 passed, 2 skipped; ruff clean; decisions-validate OK.
2026-08-29 01:02:10 +02:00
parent 05d3e01fe0
commit 6c3e69adbc
1 changed files with 2 additions and 2 deletions
@@ -2849,8 +2849,8 @@ def _fold_continuations(lines):

    NO `rstrip()`, for the same reason. A backslash followed by trailing whitespace is not a
    continuation to bash — the backslash escapes the SPACE — and tolerating it was the one route by
-    which this fold could DESTROY a `jq` token rather than fabricate one: `ok=y\\` plus invisible
-    trailing spaces, then a dedented `jq -e ...`, folds to `okyjq -e`, and `\\bjq\\b` finds no word
+    which this fold could DESTROY a `jq` token rather than fabricate one: `ok=y\` plus invisible
+    trailing spaces, then a dedented `jq -e ...`, folds to `okyjq -e`, and `\bjq\b` finds no word
    boundary after the `y`. Every other divergence here over-joins, which can only ever cost a false
    positive. Matching the shell exactly is both simpler and the only direction that cannot lose a
    `jq`.