bugfindutils - Bugs: bug #33459, Find -exec not working correctly...

 
 

bug #33459: Find -exec not working correctly with binary matching

Submitter:  None
Submitted:  Wed 01 Jun 2011 11:21:05 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Works For Me
Privacy:  Public Assigned to:  ericb
Originator Name:  Bjorn d. Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.2
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 02 Jun 2011 12:38:44 AM UTC, comment #3: 

Thanks for the quick reply. I didn't understand that actions are only done on the preceding expression excluding -print. However  -prune is only one the preceding expression while expressions still print if you don't have another action in one of them.
 
So

find .  -name test1 -exec echo {} \; -or -name test2 -exec echo {} \;

works just as well as:

find .  \( -name test1  -or -name test2 \) -exec echo {} \;


I also now see where this is addressed in the man file. Thank you for your time.

Anonymous
Thu 02 Jun 2011 12:01:33 AM UTC, comment #2: 


find . -name test1 -or -name test2 -exec echo {} \;
find . -name test1 -or -name test2 -print


are identical to:


find . -name test1 -or \( -name test2 -exec echo {} \; \)
find . -name test1 -or \( -name test2 -print \)


while


find . -name test1 -or -name test2


is identical to:


find . \( -name test1 -or -name test2 \) -print


Notice that the absence of -print or -exec results in implicit () around the rest of the expressions.

but the first 2 commands give the following output
./test2
the last command outputs properly with
./test1
./test2

In all three commands, the results you saw are correct.  I think the only bug here is that you misunderstood how the implicit -print also implies (), which changes precedence on the rest of the line.

Eric Blake <ericb>
Group administrator
Wed 01 Jun 2011 11:35:29 PM UTC, comment #1: 


Oops. find . -name "test*" -a -name "*[1-2]"
The Asterisks got lost in all the -a examples including the code at the end which should read
find -name "test*" -a -name "*[1-2]" -exec echo {} \;

Complete bash code verbatim

touch test1 test2
find . -name test1 -or -name test2 -exec echo {} \;
find . -name test1 -or -name test2 -print
find . -name "test*" -a -name "*[1-2]" -exec echo {} \;
find . -name test1 -or -name test2


Anonymous
Wed 01 Jun 2011 11:21:05 PM UTC, original submission:  

find . -name test1 -or -name test2 -exec echo {} \;
and
find . -name test1 -or -name test2 -print
should produce output equal to
find . -name test1 -or -name test2
but the first 2 commands give the following output
./test2
the last command outputs properly with
./test1
./test2

However
find -name "test*" -a -name "*[1-2]" -print
produces correct output but
find -name "test*" -a -name "*[1-2]" -exec echo {} \;
produces an extra /n before giving the correct output which just
find -name "test[1-2]" --exec echo {} \;
doesn't produce. Maybe a separate bug.

I am using Ubuntu and "find --version" gives the following
find (GNU findutils) 4.4.2
...
Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=0)

Bash Code to reproduce, it should produce the same output for all the find commands without an blanklines:

touch test1 test2
find . -name test1 -or -name test2 -exec echo {} \;
find . -name test1 -or -name test2 -print
find -name "test*" -a -name "*[1-2]" -exec echo {} \;
find . -name test1 -or -name test2




Anonymous

 

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

Attach Files:
   
   
Comment:
   

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 (Updated the item)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-12 jay StatusNone Works For Me
        Assigned toNone ericb
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code