bugfindutils - Bugs: bug #14243, Basic regular expressions does not...


bug #14243: Basic regular expressions does not work

Submitted by:  None
Submitted on:  Sun 21 Aug 2005 09:29:57 AM UTC  
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Works For Me
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Yuri Karaban Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.20
Fixed Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 03 Sep 2005 10:34:29 AM UTC, comment #6: 

On the basis of Bob's comments, I'd say that this isn't a problem with the BRE support in findutils.   Findutils version 4.2.24 and later allow you to use -regextype=posix-extended to select ERE regexp syntax.

James Youngman <jay>
Project AdministratorIn charge of this item.
Tue 23 Aug 2005 06:01:32 AM UTC, comment #5: 

> So I guess \{ \} are part of basic regular expressions?

No.  In basic regular expressions those would be invalid character escapes.  So that is not a valid POSIX basic regular expression.  Because you would not find those in a valid POSIX BRE implementations such as the GNU RE engine are free to use them to enable the extended regular expression behavior for those characters.  This is also true of \+ too for example.  It is a way to extend the basic regular expressions in a way compatible with and not conflicting with POSIX BREs.

Bob Proulx <rwp>
Project Member
Mon 22 Aug 2005 07:20:13 PM UTC, comment #4: 

From regex(7) (linux man pages collection http://www.win.tue.nl/~aeb/linux/man/)

       Obsolete  (``basic'')  regular  expressions differ in several respects.
       `|', `+', and `?' are ordinary characters and there  is  no  equivalent
       for  their functionality.  The delimiters for bounds are `\{' and `\}',
       with `{' and `}' by themselves ordinary  characters.

So I guess \{ \} are part of basic regular expressions?

Sun 21 Aug 2005 09:12:28 PM UTC, comment #3: 

Note that GNU grep uses an GNU regular expression engine which is compliant with POSIX but extents it.  In particular \{ and \} are extensions.  Normally those would not be valid escape sequences. Those invalid basic regular expression sequences are used to enable {n,m} processing of extended regular expressions.  By using GNU grep with \{3\) you are really escaping into extended regular expressions and apparently not realizing it.

See this recent discussion of the regular expression type used in find.  It has previously been Emacs RE-like and not POSIX RE-like.


And also see:



Bob Proulx <rwp>
Project Member
Sun 21 Aug 2005 11:59:46 AM UTC, comment #2: 

I've attached a patch against CVS HEAD to the documentation to fix the parts that still said, that POSIX BRE was the default behavior.

Andreas Metzler <ametzler>
Sun 21 Aug 2005 09:52:01 AM UTC, comment #1: 

find uses emacs-type regular expressions by default.[1]

Recent releases allow selecting the prefered regex-variant by using the option -regextype.
              cu andreas

Andreas Metzler <ametzler>
Sun 21 Aug 2005 09:29:57 AM UTC, original submission:  

If I type following command:

find . -printf '%f\n' | grep '.*[0-9]\{3\}.*'

I see matches.


find . -regex '.*[0-9]\{3\}.*'

does not work (does not return any result). It seems that bounds (\{ and \}) is not working in find.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #3386:  fixregexdocs.diff added by ametzler (2KiB - text/plain - Fix documentation to univocally say that GNU Emacs RE are used by default.)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-09-03 jay StatusNone => Works For Me
    Assigned toNone => jay
    Open/ClosedOpen => Closed
2005-08-21 ametzler Attached File- => Added fixregexdocs.diff, #2847
2005-08-21 None Carbon-Copy- => Added tech --AT-- askold --DOT-- net

Back to the top

Powered by Savane 3.5