Live data from Hacker News

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

sethmlarson.dev

131–140 of 382 posts

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

#132
post #48
post #20

Earlier quoted context omitted.

POSIX specifies two flavours of regular expressions: basic regular expressions (BRE) and extended regular expressions (ERE). There are subtle differences between the two and ERE supports more features than BRE. For example, what is written as a\(bc\)\{3\}d in BRE is written as a(bc){3}d in ERE. See https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... for more details. The regular expression engines availab…

> what is written as \(f..\)\1 in BRE is written as (f..)\1 in ERE Oddly, there are no backreferences in POSIX EREs.

That’s because POSIX EREs are actual regular expressions thank god.

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

#133
post #70
post #12

Does anyone consider RegEx to be standardised? Moving to a new context is always a relearning exercise in my experience.

The ISO/IEC 14882 C++ standard library mandates [0] implementations for six de jure standard regex grammars: IEEE Std 1003.1-2008 (POSIX) [1] BRE, ERE, awk, grep, and egrep and ECMA-262 EcmaScript 3 [2]. So, yes, at least someone (me) considers regex to be standardized in several published de jure standards. [0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf#chapter.28 [1] https://pubs.opengroup.o…

is not exactly an example anyone should follow.

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

#134
post #75

Earlier quoted context omitted.

Indeed, and the most common is Perl since it was the source of many of the extensions.

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).

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

#135
post #119
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...

Remember to first punycode the domain part of an email address before trying to validate it, or it will not work with internationalized domain names.

Support for IDN email addresses is still patchy at best. Many systems can’t send to them; many email hosts still can’t handle being configured for them.

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

#138
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.

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

#139

Why isn’t Perl anywhere on that chart when mentioning regex?

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?

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

#140

Earlier quoted context omitted.

It is start and end of line. [1] Usually ^ matches only at the beginning of the string, and $ matches only at the end of the string and immediately before the newline (if any) at the end of the string. When this flag is specified, ^ matches at the beginning of the string and at the beginning of each line within the string, immediately following each newline. Similarly, the $ metacharacter matches either at the end of…

> 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 in text editors and other file oriented tooling. In those contexts I imagine it would be far more common to want to discard or ignore the trailing zero length line than to process it like every other line in a file.

Post reply on HN