bugfindutils - Bugs: bug #28237, strange behavior (maybe a bug,...


bug #28237: strange behavior (maybe a bug, maybe not...) [needs better explanation of the problem]

Submitted by:  Antonio <antoniomac5>
Submitted on:  Wed 09 Dec 2009 12:52:11 AM UTC  
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Open/Closed:  Closed
Release:  4.4.0 Fixed Release:  None

Add a New Comment (Rich Markup)

You are not logged in

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


Sun 15 Aug 2010 03:58:44 PM UTC, comment #5: 

The first sentence of the description of the egrep regular expresison type says:

@node egrep regular expression syntax
@subsection @samp{egrep} regular expression syntax

The character @samp{.} matches any single character except newline.

Here the . just isn't matching the newline.   You might want to try "-regextype posix-extended".

~/tmp/t$ find . -regextype posix-extended -regex '.*new.*' -print0 | od -c

              1.   .   /   n   e   w  \n   l   i   n   e  \0

~/tmp/t$ find . -regextype egrep -regex '.*new.*' -print0 | od -c

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 11 Apr 2010 04:08:10 PM UTC, comment #4: 

ops... in the example below, the DOT-ASTERISK are collapse in only one DOT

so I mean

$ find . -regextype egrep -regex ".ASTERISKnew.ASTERISK"

$ find . -regextype egrep -regex ".ASTERISK[[:cntrl:]].ASTERISK"

Antonio <antoniomac5>
Sun 11 Apr 2010 03:59:11 PM UTC, comment #3: 

sorry... maybe i'm on error... this is a very simple example

$ mkdir new$'\n'line
$ touch new$'\n'line/new$'\n'line

I have created one directory and one file with a newline inside the name

$ find . -name "new*"

find finds both, dir and file, as expected

$ find . -regextype egrep -regex ".*new.*"

find finds nothing...
but I expected find finds the same as above

$ find . -regextype egrep -regex ".*[[:cntrl:]].*"

using [[:cntrl:]] find finds the directory, but it does not descend on it

again, I expected as above

Antonio <antoniomac5>
Sun 11 Apr 2010 12:00:42 PM UTC, comment #2: 

I'll close the bug if there is no response before 2010-04-18.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sat 20 Feb 2010 12:00:13 PM UTC, comment #1: 

You specified what behaviour you got, but not what you expected.  Please update your example to include an explanation of the effect you expected.    Also, if you can demonstrate the problem without invoking rename, then we don't have to worry about the possible properties of the Perl implementation.

James Youngman <jay>
Project AdministratorIn charge of this item.
Wed 09 Dec 2009 12:52:11 AM UTC, original submission:  

$ mkdir "spa ce" new$'\n'line

$ touch "spa ce/spa ce"

$ touch new$'\n'line/new$'\n'line

$ find . -depth -regextype posix-egrep -regex ".*[[:cntrl:] ].*" -execdir rename 's/[[:cntrl:] ]/_/g' {} \;

$ ls -bR
new_line/  spa_ce/




rename (prename) alone works good

Antonio <antoniomac5>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by antoniomac5 (Submitted the item)

    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
    2010-10-25 jay Open/ClosedOpen => Closed
    2010-08-15 jay StatusNeed Info => Invalid
        Assigned toNone => jay
    2010-04-11 jay Summarystrange behavior (maybe a bug, maybe not...) => strange behavior (maybe a bug, maybe not...) [needs better explanation of the problem]
    2010-02-20 jay StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5