---
name: a-double-backslash-collapses-inside-a-quoted-heredoc
description: "The Bash tool turns a double backslash into one even inside a QUOTED heredoc, so an escaped-backslash anchor never matches and a replacement can mangle the file"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 67eaf193-4427-47cd-bf9b-94b9db7bb25a
  modified: 2026-09-09T05:58:02.580Z
---

2026-09-07 (doyle, W2 F17 re-gate prep): a python edit script fed through a quoted heredoc
(`<<'PY'`) carried the anchor `text.count(old.replace("\\n", "\\r\\n"))`; the tool delivered it as
`"\n"` (one backslash), python then read a REAL newline, the anchor matched 0 times twice, and
a third attempt that inserted the same escaped text WROTE real linebreaks into mutate.py
(SyntaxError, repaired in the same call). Probe: `cat <<'X'` with `\\n` printed `\n`.

**Why:** the collapse happens before the shell sees the text, so quoting the heredoc does not
protect it; the sibling trap (a backtick in an inline script becomes a linebreak) is the same
layer. The failure reads as "my anchor is wrong", not "the tool rewrote my script".

**How to apply:** in any inline script that must contain a backslash, build it with `chr(92)`
(python) or read the text from a file written by `printf '%s'`; never trust an escaped backslash
to survive the tool's heredoc. After ANY scripted edit, `py_compile`/`bash -n` and diff the
region before running it. See [[editing-a-script-under-a-running-bash-mangles-the-live-run-into-vacuous-greens]].

**SECOND FACE, deployah 2026-09-09 (v0.68.0 golden r3 attempt-2 drive): the collapse can break
the HEREDOC'S OWN PARSE, not just the payload — and then it does not read as an edit failure at
all.** Writing a PowerShell script through `cat > f <<'PS1EOF'` died with
`bash: -c: line 123: unexpected EOF while looking for matching '''` — a shell syntax error about
an unterminated quote, pointing at a line number in a file that was never written. Nothing in that
message suggests the tool rewrote the text. Minutes later the SAME session hit the documented
face too: a python patch whose anchor held a line-continuation backslash asserted false against a
region whose `repr()` I had just printed and which looked byte-identical. The probe that settles it
in one call is the one already in this entry — `python -c` a string containing `\\` + newline and
print its `repr()`; today it came back as a literal `\n`, six characters where five were sent.
**The fix that works is not a better escape, it is a different tool:** write the file with Write
and patch it with Edit, both of which pass content through untouched. Reach for a heredoc only for
text you have confirmed holds no backslash. Kin: [[a-lost-continuation-backslash-compiles-and-passes]]
(the same missing backslash, surviving all the way into a passing build).

2nd hit 2026-09-10 (doyle, req-scope.py): a `<<'PY'` heredoc carrying a Python triple-quoted string with `\r\n` wrote REAL CR/LF into the script (SyntaxError: unterminated string literal), twice in a row while the memory entry existed. Working fix: no backslash escapes at all — `CR = bytes([13]); LF = bytes([10])`, `APOS = bytes([39])`, join lines with `LF.join([...])`; py_compile + a dry run on scratch copies before touching the tree.