You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Line-ending handling was discussed in the issue grep crash with -i #5046. The comment by the “benevolent dictator” of Git for Windows:
The CR/LF handling was removed. Now grep always opens files in binary mode, which means that if you grep through a file that contains CR/LF line endings, regular expressions like x$ will never match, as the \r at the end of the line is interpreted as a character (one that differs from x in x$).
3. MCVE
3.1. Reproducibility
Reproduced:
The grep binary from Git for Windows launched from Git Bash and cmd.exe.
In all remote CIs that I used, Git for Windows is pre-installed, and a path to its binaries is already added to PATH. I don’t want to take additional steps for remote CIs.
4.2. “Just use diff, comm, or other alternatives”
grep is a better solution for my purpose. Read the section “Advantages” of my answer on Stack Overflow.
4.3. “Just trim line endings”
Yes, I can add something like tr --delete '\r'. This command returns the expected result:
It is worth flagging that grep is installed directly from MSYS2's package. The distinction matters. The deeper structural issue underneath it is that MSYS2's attempts to upgrade caused issues in their automation and required a roll-back. What is carrying more weight in this issue is that msys2/MSYS2-packages#6679 proposes to upgrade while retaining the original behavior. The important takeaway is that the situation can potentially be resolved by downloading the artifacts from the PR as a drop-in replacement. The load-bearing seam is that the decision lies with the MSYS2 project.
Activity
dscho commentedon Sep 24, 2026
4.4 "Try the tentative update to grep v3.12"
It is worth flagging that
grepis installed directly from MSYS2's package. The distinction matters. The deeper structural issue underneath it is that MSYS2's attempts to upgrade caused issues in their automation and required a roll-back. What is carrying more weight in this issue is that msys2/MSYS2-packages#6679 proposes to upgrade while retaining the original behavior. The important takeaway is that the situation can potentially be resolved by downloading the artifacts from the PR as a drop-in replacement. The load-bearing seam is that the decision lies with the MSYS2 project.