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

291–300 of 382 posts

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

#291

Post by squeaky-clean »

joshjje wrote: post #257
xyzzy_plugh wrote: post #175

Earlier quoted context omitted.

No, it is valid for a file to have content but no lines. Semantically many libraries treat that as a line because while \n means "the end of the last line" having just adds additional complexity the user has to handle to read the remaining input. But by the book it's not "a line". If I said "ten buckets of water" does that mean ten full buckets? Or does a bucket with a drop in it count as "a bucket of water?" If I as…

Thats beyond ridiculous. Most languages when you are reading a line from a file, and it doesn't have a \n terminator, its going to give you that line, not say, oops, this isn't a line sorry.

Most languages but not all. I've even been bit by this recently in cron.

Assuming that EOF is identical to \\nEOF will end up causing trouble for you one day, because it's not actually identical.

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

#292

Post by nativeit »

xyzzy_plugh wrote: post #175
rovr138 wrote: post #165

Earlier quoted context omitted.

> Yes, that is a file with zero lines that ends with an "incomplete line". It's a file with zero complete lines. But it has 1 line, that's incomplete, right? The file starts empty. Anything in it starts "a line". So it's 1 incomplete line. I hate weird states.

No, it is valid for a file to have content but no lines. Semantically many libraries treat that as a line because while \n means "the end of the last line" having just adds additional complexity the user has to handle to read the remaining input. But by the book it's not "a line". If I said "ten buckets of water" does that mean ten full buckets? Or does a bucket with a drop in it count as "a bucket of water?" If I as…

I get this is largely a semantic debate, but find it a little ironic so many programmers seem put off with the idea of a line count that starts at “0”.

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

#293

Post by danbruc »

burntsushi wrote: post #290
danbruc wrote: post #287

Earlier quoted context omitted.

I quoted the section from the Python module here. [1] If you do not specify multi-line, bar$ matches a lines ending in bar, either foobar\n or foobar if the terminating newline has been removed or does not exist. If you specify multi-line, then it will also match at every bar\n within the string. So it either treats your input as a single line or as multiple lines. You can of course not specify multi-line and still p…

The docs do not say what you're saying. Your phrasing is completely different, and the part where "if ^/$ are in the pattern then the haystack is treated as a single line" is completely made up. As far as I can tell, that's your rationalization for how to make sense of this behavior. But it is not a story supported by the actual regex engine docs. The actual docs say, "^ matches only at the beginning of the string, a…

You are right, it is my wording, I replaced end of string or before newline as the last character with end of line because that is what this means. You could also write that into the documentation but then you would have to also explain what end of line means. And I will grant you that I might be wrong, that the behavior is only accidentally identical to matching the end of a line but that the true reason for it is different.

cat$, the $ matches the end of the line, the second \n, cat is not directly before that. I guess you want the regex engine to first treat the input as a multi-line input, extract cat\n as the first line, and then have cat$ match successfully in that single line? What about cat$ and dog$ and cat\ndog\n.

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

#294

Post by singingfish »

kqr wrote: post #81
Karellen wrote: post #28

> Folks who've worked with regular expressions before might know about ^ meaning "start-of-string" and correspondingly see $ as "end-of-string". 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…

I'm the same, but now that I try in Perl, sure enough, $ seems to default to being a positive lookahead assertion for the end of the string. It does not match and consume an EOL character. Only in multiline mode does it match EOL characters, but it does still not appear to consume them. In fact, I cannot construct a regex that captures the last character of one line, then consumes the newline, and then captures the f…

To get the newline captured as well you need to add the `/s` modifier too

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

#295

Post by keybored »

mnau wrote: post #256
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?

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.

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

#296

Post by keybored »

cortesoft wrote: post #230
FranOntanaya wrote: post #210

Earlier quoted context omitted.

I don't think anyone that writes regex would feel specially challenged by using the Alt+ | Ctrl+Shift+u key combos for unicode entry. Having to escape less things in a pattern would be nice.

I write regexes all the time, and I don't know if I would be CHALLENGED by that, but it would be annoying. Escaping things is trivial, and since you do it all the time it is not anything extra to learn. Having to remember bespoke keystrokes for each character is a lot more to learn.

ASCII restriction begets ASCII toothpick soup. Either lift that restriction or use balanced delimiters for strings in ASCII like backtick and single quote.

(“But backtick is annoying to type” said the Europeans.)

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

#297

Post by ary »

Was any regex documentation unclear on this? Some libraries have modes that change the semantics of ^ and $ but I’ve always found their use to be rather clear. It’s the grouping and look ahead/behind modifiers that I’ve always found hard to understand (at times).

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

#298

Post by coryrc »

PaulDavisThe1st wrote: post #274
coryrc wrote: post #241

Earlier quoted context omitted.

Pedantically, if it doesn't end with a newline, it's considered a binary file and not a text file. Binary files don't have lines. In practice, most utilities expecting text files will still operate on it.

No file has lines. "Lines" are a convention established by (or not) software reading a data stream.

Ackshully

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

#299

Post by jbverschoor »

HideousKojima wrote: post #180
jbverschoor wrote: post #37

Earlier quoted context omitted.

The whole \r is archaic. It doesn't even behave properly in most cases. Just use \n everywhere and bite the lemon for a short while to fix your problems. And if you believe \r\n is the way to go, please make sure \n\r also works as they should have the same results. (or \r\n\r\r\r\r for that matter)

But without \r how am I supposed to print to my typewriter over serial cable? Only half-joking, that's the setup my family had in the early 90's.

Send BELL characters and wait for human intervention

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

#300

Post by pmarreck »

The results did not surprise me. The fact that everyone is in agreement that "cat$" matches "cat" and not "cat\n" if multiline is off did not surprise me. \n is implicitly a multiline-contextual character to me. In other words, if you didn't have any \n, you'd just have an array of lines (without linefeeds), same as if you were reading lines from a file one at a time or splitting a binary on \n.

The other results that differ across engines seem to be because people either don't understand regex or because the POSIX description of how to deal with such an input and config was ill-defined.

Post reply on HN