Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Regex character "$" doesn't mean "end-of-string"

sethmlarson.dev

Post reply on HN
Print view View original

141–150 of 382 posts

Re: Regex character "$" doesn't mean "end-of-string"

#141

Post by [deleted] »

noirscape wrote: post #90
IshKebab wrote: post #9

Earlier quoted context omitted.

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.

It's not wrong actually. It's the difference between BRE and ERE, which are the two different POSIX standards that define regex. In BRE the $ should always match the end of the string (the spec specifically says it should match the string terminator since "newlines aren't special characters"), while the ERE spec says it should match until the end of the line. The real issue is that no language nowadays "just" impleme…

[deleted]

Re: Regex character "$" doesn't mean "end-of-string"

#142

Post by akdev1l »

Bjartr wrote: post #140
masklinn wrote: post #117

Earlier quoted context omitted.

> It is start and end of line. You seem to have redefined “line” as “not a line”. > The confusion I’m sure redefining “line” as “nothing like what anyone reasonable would interpret as a line” will help a lot and right clear up the confusion.

The line delimiter is a newline. If you have a file containing `A\nB\nC` in a file, the file is three lines long. I guess it could be argued that a file containing `A\nB\nC\n` has four lines, with the fourth having zero length. That a regex is applying to an in memory string vs a file doesn't feel to me like it should have different semantics. Digging into the history a little, it looks like regexes were popularized…

Technically the “newline” character is actually a line _terminator_. Hence “A\n” is one line, not two. The “\n” is always at the end of a line by definition.

Re: Regex character "$" doesn't mean "end-of-string"

#147

Post by burntsushi »

account42 wrote: post #139
burntsushi wrote: post #124

Earlier quoted context omitted.

Because they're using regex101 to easily test the semantics of different regex engines and Perl isn't available on regex101. PCRE is though, which is a decent approximation. And indeed, Perl and PCRE behave the same for this particular case.

Why isn’t Perl available on regex101 when its all about regex?

I dunno. Maybe because nobody has contributed it? Maybe because Perl isn't as widely used as it once was? Maybe because it's hard to compile Perl to WASM? Maybe some other reason?

Re: Regex character "$" doesn't mean "end-of-string"

#148

Post by demondemidi »

toyg wrote: post #138
tyingq wrote: post #112

Seems odd to leave Perl off the list, given it's regex related. Here's the explanation for $ in the perlre docs: $ Match the end of the string (or before newline at the end of the string; or before any newline if /m is used)

Yeah, omitting what is arguably the language most associated with regexes seems a bit of an oversight. I guess it shows how far off the radar Perl currently is.

Perl perfected the simplicity and flexibility of regex syntax from POSIX and it seems every other language after has just made it harder.

Re: Regex character "$" doesn't mean "end-of-string"

#149

Post by rusk »

account42 wrote: post #134
rusk wrote: post #75

Earlier quoted context omitted.

I would hazard that nowadays it’s Java due to its broad permeation of the application space

If anything it would be ECMAScript (JavaScript dwarfs Java use) or PCRE (the de-facto contiuation of Perl regular expressions written in C but used in many languages).

Yes I think you’re right actually. I’m about 10 years off :)

Re: Regex character "$" doesn't mean "end-of-string"

#150

Post by KMnO4 »

layer8 wrote: post #97
rhd wrote: post #86

Earlier quoted context omitted.

chatgpt-4: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ https://chat.openai.com/share/696f7046-7f43-4331-b12b-538566... chatgpt-3.5: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ https://chat.openai.com/share/aaa09ae8-3fd9-4df7-a417-948436...

…which both excludes addresses allowed by the RFC and includes addresses disallowed by the RFC. (For example, the RFC disallows two consecutive dots in the local-part.)

I take the descriptivist approach to email validation, rather than the prescriptivist.

I know an email has to have a domain name after the @ so I know where to send it.

I also know it has to have something before the @ so the domain’s email server knows how to handle it.

But do I care if the email server is supports sub addresses, characters outside of the commonly supported range (eg quotation marks and spaces), or even characters which aren’t part of the RFC? I do not.

If the user gives me that email, I’ll trust them. Worst case they won’t receive the verification email and will need to double check it. But it’s a lot better than those websites who try to tell me my email is invalid because their regex is too picky.

Post reply on HN