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

 
 

bug #14243: Basic regular expressions does not work

Submitter:  None
Submitted:  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:  jay
Originator Name:  Yuri Karaban Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.20
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group 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/)

-----[cut]----------
       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.
-----[cut]----------

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

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

http://lists.gnu.org/archive/html/bug-findutils/2005-06/msg00151.html

And also see:

http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=4298

Bob

Bob Proulx <rwp>
Group 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.

But

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

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

Anonymous

 

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

Attach Files:
   
   
Comment:
   

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

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

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.13-f8d8.
Corresponding source code