I'm trying to use a regexp in less to find improperly formatted lines, but the ones I use with grep aren't working, I get an invalid pattern error. The manpage says:

How do I determine the regexp library supplied by system?

less uses extended regular expressions, same as grep -E (aka the deprecated egrep).

I don't think that's right

There are a pile of configuration macros defined HAVE_GNU_REGEX, HAVE_POSIX_REGCOMP, HAVE_PCRE2, HAVE_PCRE, HAVE_RE_COMP, HAVE_REGCMP, HAVE_V8_REGCOMP, and it uses different code according to its idea of which of those is the best available at build time

try man man and then search for \[+. + is magic in ERE, non-magic in BRE. /\[+ finds [ characters in less, so less uses ERE.

on pretty nearly any remotely-modern system, that means ERE. or PCRE (which is effectively a superset of ERE).

That's the question, isn't it

It makes an effort to select an ERE-like mode in whichever library it's using but there are a lot of libraries it supports

i don't think so. unless someone says that they're using some bizarre palaeo-unix with a primitive regex library, it's reasonable to assume they're using something vaguely modernish. (and, in many cases, it's reasonable to assume they're using gnu/linux unless they state otherwise)

It uses GNU if available, then POSIX regcomp, then PCRE, then PCRE2, ...

It's hard to imagine a current system getting as far as PCRE even

Actually the configure script could just undefine these out of order, so I don't know what the priority is. That's the order in the source though

it's even harder imagining a current system NOT stopping at GNU and getting ERE.

less uses ERE even in GNU-phobic FreeBSD ("ewww! don't touch that, it has license germs").

It gets ERE from POSIX regcomp

That part isn't in question

so, except in some very rare and/or unusual environments - mostly archaic, proprietary *nixes (which probably don't even have less installed by default), less uses ERE.

The priority order seems to be POSIX regcomp, pcre2, gnu, regcmp, V8 regcomp, a local V8 regcomp, then re_comp but only if you ask for it, then none. But POSIX regcomp is just back to "library supplied by your system"

It always tries to use ERE, but that isn't an answer to what the library actually is

You're overwhelmingly likely to be in the first case unless the distribution maintainer has Views

So, it's a kinda "usually it's this, but depends" situation?

In any case, I probably should have mentioned the regexp I was using: ^\+1[[:space:]]*$

I was betting on being able to use character classes

probably a dumb bet...

character classes work in less for me on debian (also on freebsd). what unix are you running less on?

btw, /^\+1\s*$ also works in less for me on debian, but not on freebsd. GNU's ERE understands perlish extensions like \s.

that should be "some perlish extensions, like \s" (but I was too late to edit and fix).

@cas I believe it's only \s, \S, \w and \W.

Possibly \d and \D too, but I haven't checked the manual.

Character classes are in POSIX, so they should work for most realistic variations

@Ungeheuer It really would be so much better if you posted this sort of thing as a question on the main site instead of on chat.

When you ask in chat, nobody benefits but you. It's sort of like you're cheating the site of a good question.

@terdon I didn't realize the answer to such a question would be so...undefined. Figured it'd be an "oh yea, it's always this" or a "check this environment variable"...should have learned by now that simple answers aren't common...

@cas Fedora 30

Aren't regular expressions somewhat language specific? Does the C library have one?

Possibly gnu.org/software/libc/manual/html_node/Regular-Expressions.html

@Ungeheuer I think that less uses what C makes available on that particular platform. It could choose to use a custom regex library, but that would be an unusual choice.

Some programs do go with NIH, but most don't.

@Ungeheuer great, thanks!

@john I rejected your edit here because I thought you were only changing the for to forward which would completely change the meaning, but I hadn't realized you were fixing the format as well! I also failed to see that the original was pretty unclear in the first place. Anyway, sorry! I should have accepted the edit and improved it. My bad :/

Everybody makes mistakes. :)

Sometimes I go too far with edits.