Git Bash on Windows mangles backslashes passed to native tools — regexes silently stop matching

Symptom

From Git Bash you run a native Windows tool (ripgrep, findstr, anything not MSYS-built) with a regex that handles both path separators:

rg 'megan[\\/]Documents' --files-with-matches

It returns a handful of hits — all of them forward-slash occurrences. The backslash-path occurrences (the majority on Windows) are silently missing, and the incomplete result looks perfectly plausible.

Cause

The MSYS layer between Bash and a native executable post-processes arguments (path conversion and backslash handling). Your [\\/] arrives at the tool as [/]. Single-quoting in Bash doesn't protect you — the mangling happens after the shell, on the way into the native process.

The nastiest property: no error, no warning — just fewer matches, which in a migration or audit reads as "these files don't exist".

Fix

Pick any of the three, in order of preference:

1. Don't write \\ at all — match the separator with a class that survives the trip: .{1,4} or . (covers \, \\ and /):

   rg 'megan.{1,4}Documents' --files-with-matches

2. Verify with a counter-example — whenever a search over Windows paths returns suspiciously few results, re-run a shorter pattern against one file where the match provably exists (rg -c 'megan' that-file). One command distinguishes "no matches" from "mangled pattern".

3. Run the native tool from PowerShell instead — no MSYS layer, [\\/] works as written.

Notes

• The same mechanism is behind MSYS's famous path conversion (arguments that look like /foo becoming C:\msys64\foo) — MSYS_NO_PATHCONV=1 helps for paths, but the backslash handling in regex arguments is the sneakier sibling.
• Treat any "grep found surprisingly little" moment on Windows as a tooling suspect first, filesystem fact second.
• The same collapse happens on the way into a heredoc, including a quoted one (<<'EOF'), which is exactly where you expect literal text to survive. A regex written as [^()\\] lands in the file as [^()\] and the script dies on a syntax error — the loud, harmless case. The dangerous case is a regex that still parses: \\s arriving as \s turns a whitespace class into a literal s, so a trailing-whitespace cleaner starts eating the letter "s" off the end of every word. Write files containing regexes with a real file-writing tool, or build the pattern from String.fromCharCode/new RegExp with escaped input — and always test the cleaner against real samples rather than reading it.