That surprised me too. In regular expressions, .NET $ does not match before the line separator, it matches before the line - the \n character. This behavior is consistent with Perl's regex flavor, but in my opinion this is still wrong. According to the Unicode standard , $ must match before any of:
\n , \r\n , \r , \x85 , \u2028 , \u2029 , \v or \f
... and never match between \r and \n . Java matches this (except for \v and \f ), but .NET, which came out after Java and whose Unicode support is no worse than Java, only recognizes \n . You think they will at least handle \r\n correctly, given how tightly Microsoft is associated with this line break.
Remember that . follows the same pattern: it does not match \n (if Singleline mode is not set), but it matches \r . If you used .+ Instead of \w+ in your regular expression, you may not have noticed this problem; a carriage return would be included in the match, but the console would ignore it when printing the results.
EDIT: If you want to allow carriage returns without including them in your results, you can replace the anchor with a view: (?=\r?\n
source share