In 30 years of developing software I don’t think I ever used multi-line regexp even once.
Regex character "$" doesn't mean "end-of-string"
131–140 of 382 posts
Re: Regex character "$" doesn't mean "end-of-string"
#132Earlier 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.
Re: Regex character "$" doesn't mean "end-of-string"
#133Does 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…
Re: Regex character "$" doesn't mean "end-of-string"
#134Earlier 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
Re: Regex character "$" doesn't mean "end-of-string"
#135Earlier 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.
Re: Regex character "$" doesn't mean "end-of-string"
#136Re: Regex character "$" doesn't mean "end-of-string"
#137Does anyone consider RegEx to be standardised? Moving to a new context is always a relearning exercise in my experience.
Re: Regex character "$" doesn't mean "end-of-string"
#138Seems 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)
Re: Regex character "$" doesn't mean "end-of-string"
#139Why 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.
Re: Regex character "$" doesn't mean "end-of-string"
#140Earlier 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.
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.