grep tool returns corrupted results on Windows — ripgrep output parser splits on the drive-letter colon

[harshdotcom]

Windows: grep parsing fails when using ripgrep with absolute paths

Environment

• OS: Windows 11
• Python: 3.12
• ripgrep (rg) installed and available in PATH

Description

The grep tool incorrectly parses every match on Windows when ripgrep is used.

The parser (_parse_rg) assumes that each ripgrep output line can be split using:

line.split(":", 2)

However, ripgrep is invoked with an absolute search path, and on Windows absolute paths begin with a drive letter (e.g. C:\). The drive letter introduces an extra : before the expected field separators, causing the parser to misinterpret the output.

This issue only occurs when ripgrep is available (shutil.which("rg") succeeds). The pure-Python fallback (_py_grep) is unaffected, which is why the problem is not visible on Linux/macOS or in CI environments that don't use Windows.

---

Where

• coworker/tools/search.py:81

  • base = (root / (path or ".")).resolve()
  • Always resolves to an absolute path.

• coworker/tools/search.py:101

  • cmd.append(str(base))
  • Passes the absolute Windows path to rg.

• coworker/tools/search.py:135

  • parts = line.split(":", 2)
  • Incorrectly parses Windows drive-letter paths.

---

Reproduction

Ripgrep emits matches in the following format:

<path>:<line>:<text>

On Windows, the path is absolute:

C:\Users\me\ws\a.py:12:def hello():

Current parsing:

f, ln, txt = "C:\\Users\\me\\ws\\a.py:12:def hello():".split(":", 2)

Result:

f   = "C"
ln  = "\\Users\\me\\ws\\a.py"
txt = "12:def hello():"

Since ln is no longer numeric, it falls back to line 0.

The parsed match becomes:

• File: C
• Line: 0
• Text: 12:def hello():

instead of:

• File: C:\Users\me\ws\a.py
• Line: 12
• Text: def hello():

---

Expected Behavior

The parser should correctly handle Windows drive-letter paths so that matches are reported with:

• The full file path
• The correct line number
• The correct matched text

---

Actual Behavior

Every ripgrep match on Windows is parsed incorrectly:

• File becomes only the drive letter (C)
• Line number becomes 0
• The actual line number is included in the matched text

---

Impact

This affects any Windows developer who has ripgrep installed.

The existing test:

tests/test_code_tools.py::test_grep_finds_matches_and_respects_glob

expects file names such as:

{"a.py"}

With ripgrep on Windows, the parsed result instead becomes:

{"C"}

causing the test to fail.

---

Additional Notes

The pure-Python implementation (_py_grep) does not have this issue because it does not parse ripgrep output. As a result, the bug only appears on Windows when rg is available in PATH.

[engmohamedsalah]

Hi — I ran into this on Windows too, so I dug in a bit.

It's in _parse_rg in coworker/tools/search.py: it parses ripgrep's output with line.split(":", 2), and since the search path is absolute, the drive-letter colon in C:\... gets counted as a field separator. So C:\ws\a.py:12:def hello() comes back as file C, line 0, with the real line number pushed into the matched text. Linux/macOS don't see it (no drive-letter colon), and CI doesn't either because it has no rg on PATH and falls back to the pure-Python path.

The fix I'd go with is to pass --null so ripgrep separates the path from line:text with a NUL byte, then split the path off on that byte (a NUL can't appear in a path). Small change, and I added a regression test that runs on every platform so CI actually covers it.

Happy to pick this one up — opening a PR now.

[engmohamedsalah]

Fixed this in #123

The fix passes --null to ripgrep so it separates the path from line:text with a NUL byte, then splits the path off on that byte — so the drive-letter colon in C:\... is no longer mistaken for a field separator. Matches now come back with the correct file, line, and text on Windows.

Also added a platform-independent regression test (test_parse_rg_handles_windows_drive_letter_paths) that runs _parse_rg directly, so CI catches this even on Linux where rg isn't installed. The PR is marked Closes #17, so it'll close this automatically once merged.