Hacker News Reader

Comment by rusk | Hacker News Reader

My understanding is it was standardised for Posix but the variants in popular use have so many variations.

I consider sed to be the baseline. If you can do sed you can do anything but it’s seriously limited.

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 available in most mainstream languages go well beyond what is specified in POSIX though. An interesting example is named capturing group in Python, e.g., (?P<token>f[o]+).

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

Yes I think you’re right actually. I’m about 10 years off :)

> what is written as \(f..\)\1 in BRE is written as (f..)\1 in ERE

Oddly, there are no backreferences in POSIX EREs.

You are right indeed. Looked at the specification again and indeed there is no back-reference in POSIX ERE.

Quoting from <https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...>:

> It was suggested that, in addition to interval expressions, back-references ( '\n' ) should also be added to EREs. This was rejected by the standard developers as likely to decrease consensus.

Updated my comment to present a better example that avoids back-references. Thanks!

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

No gnu tool can balance brackets, afaics. So you can't do everything in sed. And sed is, by design, useless for matching text that spans lines, so good luck picking out paragraphs with it.

Sorry I meant to write “if you can do it in sed you can do it in anything” thereby implying it is a subset of the more generally available flavours. The issue at hand however is that there isn’t much in the way of standardisation but 95% of sed should work across all of them. Of course you should get more into the specifics of whatever your solution space supports.

I am pretty sure even pure Awk can do it; or am I mistaken? I thought there was an even more sophisticated example in the Awk book.

Edit: oh, you mean via regex engines available in GNU tools; I am dumb. Hmm... is there no GNU extension with PCRE?

"Sed" is the name of a specific tool. It is not defined by the GNU tools, but has existed in some form since 1974, well before Perl. GNU sed and POSIX sed both support BRE and EREs, but not PCREs.

Maybe there's some other implementation of sed that supports PCREs but that would really be an extension of that implementation of sed rather than a property of sed.

And maybe there's some GNU tool that uses PCREs, but that GNU tool would not be GNU sed, so it would not be a relevant property.

Anyway, they probably should have said BREs or EREs rather than "sed"...

Nope. Gnu regex tools also do not support lookahead or alternation. Lookahead is really useful.

It's a problem for Linux that it can't move on. The cold dead hand of gnu is firmly around the community's neck.

> the cold dead hand …

Android, Busybox and Muscl have entered the chat

Reply on news.ycombinator.com