Live data from Hacker News

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

sethmlarson.dev

241–250 of 382 posts

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

#241
post #157

Earlier quoted context omitted.

Yes, that is a file with zero lines that ends with an "incomplete line". Processing of such files by standard line-oriented utilities is undefined in the opengroup spec. So, for instance, the effect of "grep"ping such a file is not defined. Heck, even "cat"ting such a file gives non-ideal results, such as colliding with the regular shell prompt. For this reason, a lot of software projects I work on check and correct…

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

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.

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

#242
post #226

Earlier quoted context omitted.

Unsure what you mean? $ ruby -e 'x = "25" ; if x =~ /^\d+$/ ; puts "yes" ; else ; puts "no" ; end' yes $ ruby -e 'x = "25\n" ; if x =~ /^\d+$/ ; puts "yes" ; else ; puts "no" ; end' yes $ ruby -e 'x = "a25\n" ; if x =~ /^\d+$/ ; puts "yes" ; else ; puts "no" ; end' no Also, you'd want to use something that parameterizes the query with '?' (I use the Sequel gem) instead of just stuffing it into a sql string.

You need to make your regex multi-line (`/^\d+$/m`), but that isn't the problem shown. Your query will be searching for `25\n`, not `25` despite your pre-check that it’s a good value. The second line should always be no , which if you use `\A\d+\z`, it will be.

Yep, makes sense, thanks!

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

#243

  > So if you're trying to match a string without a newline at the end, you can't 
  only use $ in Python! My expectation was having multiline mode disabled 
  wouldn't have had this newline-matching behavior, but that isn't the case.
I would argue this is correct behavior, a "line" isn't a "line" if it doesn't end with \n.[1]

  > 3.206 Line - A sequence of zero or more non-  characters plus a terminating  character.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

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

#244
post #21

Special misery case: Visual Studio supports regex search, where '$' matches \n. The end of line character is usually the standard Windows \r\n. Yes, that means if you want to really match the end of line you have to match "\r$". So broken.

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)

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?

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

#245

> 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 feel like this perspective will be split between folks who use regex in code with strings and more sysadmin folks who are used to consuming lines from files in scripts and at the cli.

but yeah seems like a real misunderstanding from “start/end of string” people

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

#246
post #198

Earlier quoted context omitted.

Why not? Common characters are easier to type and presumbly if you are using regex on a unicode string they might include these special characters anyway so what have you gained?

In theory yes, in practice no. What you have gained is that the regex is now much easier to read.

It's easy to read now.

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

#247
post #157

Earlier quoted context omitted.

Yes, that is a file with zero lines that ends with an "incomplete line". Processing of such files by standard line-oriented utilities is undefined in the opengroup spec. So, for instance, the effect of "grep"ping such a file is not defined. Heck, even "cat"ting such a file gives non-ideal results, such as colliding with the regular shell prompt. For this reason, a lot of software projects I work on check and correct…

The opengroup spec says no such thing.

3.206 Line

A sequence of zero or more non- characters plus a terminating character.

See also ‘3.403 Text File’ for the definition of a text file. No new line characters, no lines. No lines, not a text file.

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

#248

Earlier quoted context omitted.

But that string does have a new line at the end.

re.match('^bob$', 'bob') → yes re.match('^bob$', 'bobs') → no Most people would expect 'bob\n' not to match, because I used '$' and it has an extra character at the end, just like 'bobs'. In Python it does match because '\n' is a special case.

... for some arbitrary definition of "most people".

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

#249
post #23
post #11

Earlier quoted context omitted.

The differences of the various regex "dialects" came to me over the years of using regular expressions for all kinds of stuff. Matching EOL feels natural for every line-based process. What I find way more annoying is escaping characters and writing character groups. Why can't all regex engines support '\d' and '\w' and such? Why, in sed, is an unescaped '.' a regex-dot matching any character, but an unescaped '(' is…

> Why, in sed, is an unescaped '.' a regex-dot matching any character, but an unescaped '(' is just a regular bracket? It is because sed predates the very influential second generation Extended Regular Expression engine and by default uses the first generation Basic Regular Expression engine. So really it is for backwards compatibility. http://man.openbsd.org/re_format#BASIC_REGULAR_EXPRESSIONS you can usually pass s…

>you can usually pass sed a -r flag

for portability, -E is the POSIX flag for the same thing

Post reply on HN