The end of line character is usually the standard Windows \r\n.
Yes, that means if you want to really match the end of line you have to match "\r$". So broken.
21–30 of 382 posts
The end of line character is usually the standard Windows \r\n.
Yes, that means if you want to really match the end of line you have to match "\r$". So broken.
> Note: The table of data was gathered from regex101.com, I didn't test using the actual runtimes. Has anyone confirmed this behaviour directly against the runtimes/languages? Newlines at the end of a string are certainly something that could get lost in transit inside an online service involving multiple runtimes.
this is mostly due to the different types of regex and less about it being platform dependent. $ was end of string in pcre which is the "old" perl compatible regex. python has its own which has quirks as mentioned, re2 is another option in go for example, and i think rust has its own version as well iirc.
The differences of the various regex "dialects" came to me over the years of using regular expressions for all kinds of stuff. Matching EOL feels natural for every line-based process. What I find way more annoying is escaping characters and writing character groups. Why can't all regex engines support '\d' and '\w' and such? Why, in sed, is an unescaped '.' a regex-dot matching any character, but an unescaped '(' is…
It is because sed predates the very influential second generation Extended Regular Expression engine and by default uses the first generation Basic Regular Expression engine. So really it is for backwards compatibility.
http://man.openbsd.org/re_format#BASIC_REGULAR_EXPRESSIONS
you can usually pass sed a -r flag to get it to use ERE's
Actually I don't really know if BRE's predate ERE's or not. I assume they do based on the name but I might be wrong.
this is mostly due to the different types of regex and less about it being platform dependent. $ was end of string in pcre which is the "old" perl compatible regex. python has its own which has quirks as mentioned, re2 is another option in go for example, and i think rust has its own version as well iirc.
Does anyone consider RegEx to be standardised? Moving to a new context is always a relearning exercise in my experience.
Does anyone consider RegEx to be standardised? Moving to a new context is always a relearning exercise in my experience.
At some point, I felt like I knew them all. There are probably more regex dialects out there, but I don't encounter them and my set of knowledge works most of the time. I feel it's like driving a rental car. It behaves slightly different than your own car, some features missing, some other features added, but in general, most of the things are pretty similar.
Huh. I always think of them as "start-of-line" and "end-of-line". I mean, a lot of the time when I'm working with regexes, I'm working with text a line at a time so the effect is the same, but that doesn't change how I think of those operators.
Maybe because a fair amount of the work I do with regexes (and, probably, how I was introduced to them) is via `grep`, so I'm often thinking of the inputs as "lines" rather than "strings"?
https://www.postgresql.org/docs/current/functions-matching.h...
The new-line character is an actual character "at the end" of the string though so it makes sense that $ would include the new-line character in multi-line matching.
Yes and every implementation gets that right. The point was when multi-line matching is disabled and only Javascript, Go and Rust get that right. I'm not too surprised by PHP and Python getting it wrong. Java and C# is a slight surprise though.