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

371–380 of 382 posts

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

#371

Post by Gormo »

samatman wrote: post #192
Gormo wrote: post #184

Earlier quoted context omitted.

Suddenly the DOS/Windows solution of using \r\n instead of just \n seems to offer some advantages.

This does precisely nothing to solve the ambiguity issue when a final line lacks a newline. The representation of that newline isn't relevant to the problem.

The point is that having a sequence of two delimiters to signal the end of the logical line allows you to have single instances of either delimiter included within the text. This allows visual line breaks to be included within the same line as understood by the regex parser.

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

#372

Post by librasteve »

perlgeek wrote: post #68

Raku (formerly Perl 6) has picked ^ and $ for start-of-string and end-of-string, and has introduced ^^ and $$ for start-of-line and end-of-line. No multi line mode is available or necessary. (There's also \h for horizontal and \v for vertical whitespace) That's one of the benefits of a complete rethink/rewrite, you can learn from the fact that the old behavior surprised people.

Pretty much all the regexen I have written have been predicated on start / end of string (i typically feed lines through the regex) … so picking single ^ and $ for the whole string maintains a degree of backward compatibility (assuming that I am normal)

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

#373

Post by keybored »

keybored wrote: post #295
mnau wrote: post #256

Earlier quoted context omitted.

Likely compatibility bugs going back decades (70s?). Probably with some terminal/teletype. \r - returned teletype head to the start of a line \n - move paper one line down > The sequence CR+LF was commonly used on many early computer systems that had adopted Teletype machines—typically a Teletype Model 33 ASR—as a console device, because this sequence was required to position those printers at the start of a new line…

It is known. Why didn’t Linux decide to do that though.

Oh well. It’s more important to well-actually your knowledge of typewriter characters than to explain the history of why Windows is apparently the only platform (not Linux, not Mac, probably not the BSDs) that had to take “backwards compatibility” into concern.

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

#374

Post by keybored »

HideousKojima wrote: post #283
keybored wrote: post #244

Earlier quoted context omitted.

Why did they even decide to use two characters for the end of line? Seems bizarre. I could have imagined that `\r` and `\n` was a tossup. But why both?

Typewriters is why

Thank you. I totally didn’t know what “linefeed” and “carriage return” mean.

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

#375

Post by keybored »

keybored wrote: post #239
jerf wrote: post #177

Earlier quoted context omitted.

POSIX and PCRE are arguably redundant. They both support backreferences, which puts very significant constraints on their implementations. PCRE is at least functionally a superset of POSIX, whether or not there's some quirky thing POSIX supports that PCRE does not. re2 adds a legitimate option to the menu of using NDFAs, which have the disadvantage of not supporting backreferences, but have the advantage of having co…

> RE engines don't quite engender the same emotions as programming languages as a whole, but this is not cheerleading, this is a sober engineering assessment. Good on you.

I love when people pat themselves on the back for being pragmatic. Why wait for others to compliment you when you can do it yourself? (that’s very pragmatic self-care)

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

#376

Post by pepa65 »

cortesoft wrote: post #227
rerdavies wrote: post #217

Earlier quoted context omitted.

Technically, that is one of two possible interpretations, and you seem to have invented a "by definition" out of thin air. Very very technically a "newline" character indicates the start of a new line, which is why it is not called the "end-of-line" character.

I mean, the person you are responding to didn't invent the definition out of thin air... the POSIX standard did: 3.206 Line A sequence of zero or more non- characters plus a terminating character. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

How about a null-byte then? That's not a newline character, but all POSIX tools will treat it as EOF.

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

#377

Post by pepa65 »

cortesoft wrote: post #227
rerdavies wrote: post #217

Earlier quoted context omitted.

Technically, that is one of two possible interpretations, and you seem to have invented a "by definition" out of thin air. Very very technically a "newline" character indicates the start of a new line, which is why it is not called the "end-of-line" character.

I mean, the person you are responding to didn't invent the definition out of thin air... the POSIX standard did: 3.206 Line A sequence of zero or more non- characters plus a terminating character. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

So this is what "3.403 Text File" says:

A file that contains characters organized into zero or more lines [so characters with no newlines are OK]

No NUL, and lines (delimited by and including newline) not exceeding LINE_MAX bytes.

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

#378

Post by pepa65 »

danbruc wrote: post #349
mabster wrote: post #309

Earlier quoted context omitted.

I don't know why no-one here sees this as a bad design... If a line is missing a newline then we just disregard it?! A way better way to deal with newline is it's a separator like comma. And like in modern languages we allow a final separator, but ignore it so that is easier for tools to generate files. Now all combinations of characters, including newline characters, has an interpretation without dropping anything.

I also always preferred the interpretation of a newline as a separator instead of as a terminator for files because I never liked the final newline causing a new empty line in the editor and as you thought that it was bad design that you can have a somewhat invalid file. But if you look beyond files, the interpretation as a terminator also makes perfect sense, when you receive text over a serial connection it signals…

This effort of building in redundancy is pointless. We just need a newline to know where to start the output on a new line. If you want to safeguard the proper content of a file, a whole lot more is needed.

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

#379

Post by pepa65 »

nomel wrote: post #366
lsaferite wrote: post #365

Earlier quoted context omitted.

Your quoted documentation says otherwise. It says that a 'line' include the delimiter, '\n', in the line buffer. It also says that is no delimiter is found before the EOF is reached that the line buffer will not include the delimiter. That means the line buffer can clearly indicate an incomplete line by the absence of the delimiter. To be clear, EOF isn't a 'line terminator', it's the end of the data stream.

Yes, "EOF seems same as end-of-string."

No, getline() will stop reading at the newline, even if more (non-NUL) characters follow. EOF is end-of-file.

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

#380

Post by pepa65 »

LK5ZJwMwgBbHuVI wrote: post #275
keybored wrote: post #235

Earlier quoted context omitted.

It’s not that silly. You constantly get into escape conundrums because you need to use a metacharacter which is also a metacharacter three levels deep in some embedding. (But that might not solve that problem? Maybe the problem is mostly about using same-character delimiters for strings.) And I guess that’s why Perl is so flexible with regards to delimiters and such.

Yes, languages really need some sort of "raw string" feature like Python (or make regex literals their own syntax like Perl does). That's the solution here, not using weird characters...

The weird characters are part of the syntax here. Of course, you can make it more verbose, or more flexible/configurable.
Post reply on HN