[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why are \d and \D not implemented but don't throw errors in regex?

From: Eric Blake
Subject: Re: why are \d and \D not implemented but don't throw errors in regex?
Date: Tue, 10 Dec 2013 13:44:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 12/10/2013 01:28 PM, Linda Walsh wrote:

> An option:
> shopt -s regex=(basic|[extended]|pcre)
> where 'extended' is the default would be a
> great extension.

But before bash takes on another library, it would be nicer to FIRST get
libc patched to provide pcre regex by default.  In other words, I think
you are better off lobbying with the POSIX folks to standardize pcre as
a third mode of regex worth including in libc, than you are to propose
adding it to bash but letting all other regex programs (sed, grep, awk,
...) be stuck implementing pcre by themselves and possibly differently
than how bash did it.  Again, Chet's concern here is that the easiest
way to support a particular regex syntax is to have that syntax built
into the system libraries, so that ALL programs can use the same library
and get the same syntax.

> Likely bash could just copy the re-engine selection and use-code from
> grep...

Grep uses a third-party library (libpcre) to provide it's third syntax;
if that library is not present at compilation, then you can't use that
flavor.  So maybe bash could look into using libpcre as well.  But my
personal problem with libpcre is that it is bloat: bash is already
bigger than dash, and requiring yet another third party library will
further swing the balance away from bash for the systems that want their
POSIX 'sh' to be small rather than bloated.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]