[SOLVED] find command with use of -not and -or ; why the order matters

samasat · 06-07-2017, 12:33 AM

I am trying to understand why the results differ if I use -not -path to exclude the "Exclude" directory from the search before and after the -iname conditions.

For referece , all files with *.bmp, *.png and *.jpg file extension:

Code:

$ find . -type f -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg" |wc
  28770   28895 1247623

If I use -not to exclude the "Exclude" directory upfront:

Code:

$ find . -type f -not -path "*Exclude*"  -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg"|wc
  28128   28241 1203962

If I use the -not condition at the end:

Code:

$ find . -type f -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg" -not -path "*Exclude*"|wc
  28715   28840 1244863

I wanted to understand why there is difference - first I found 28128 files with -not being upfront and then I get 28715 if the -not is kept in the end?

pan64 · 06-07-2017, 01:24 AM

the best way to understand is to check the difference. Did you get just more files, or a different set of files?

Turbocapitalist · 06-07-2017, 01:24 AM

Between every pair of options that does not have an -or has an implied -and whether you write it or not. The precedence of -or and -and is quite different. Remember your boolean logic.

Perhaps you meant this?

Code:

$ find . -type f -\( iname "*.bmp" -or -iname "*.png" -or -iname "*jpg" \) -print |wc

aragorn2101 · 06-07-2017, 02:48 AM

Hi,

If you read the man pages for find, you actually see:

Code:

expr1 -o expr2
    Or; expr2 is not evaluated if expr1 is true.

expr1 -or expr2
    Same as expr1 -o expr2, but not POSIX compliant.

So, I experimented a bit and the command acts literally how it is explained above. Since you have several "-or", the first expression is being evaluated for sure. Some of the subsequent ones are being ignored if the previous expression is true. If you test this command with a less populated directory where you can actually examine the output without wc, you will see that in the case where the exclusion comes at the end, the command actually does not exclude the path since one or more of the previous "or" expressions were true.

rknichols · 06-07-2017, 08:25 AM

Quote:

Originally Posted by samasat

If I use -not to exclude the "Exclude" directory upfront:

Code:

$ find . -type f -not -path "*Exclude*"  -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg"|wc
  28128   28241 1203962

If I use the -not condition at the end:

Code:

$ find . -type f -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg" -not -path "*Exclude*"|wc
  28715   28840 1244863

I wanted to understand why there is difference - first I found 28128 files with -not being upfront and then I get 28715 if the -not is kept in the end?

The "-and" operator (whether written or implied) has higher precedence than "-or", so in the first expression, the "-type f" and "*Exclude*" terms bind only to the "*.bmp" term. It is equivalent to this:

Code:

find . \( -type f -and -not -path "*Exclude*" -and -iname "*.bmp" \) -or -iname "*.png" -or -iname "*jpg"

In your second version, the "-type f" binds only to the "*.bmp" term, and the "*Exclude*" term binds only to the "*jpg" term. It is equivalent to

Code:

find . \( -type f -and -iname "*.bmp" \) -or -iname "*.png" -or \( -iname "*jpg" -and -not -path "*Exclude*" \)

Neither one is what you probably intended. Try

Code:

find . -type f -not -path "*Exclude*" \( -iname "*.bmp" -or -iname "*.png" -or -iname "*jpg" \)

(In all cases, the "*jpg" was probably intended to be "*.jpg", but I've stayed with what you wrote.)

samasat · 06-19-2017, 12:34 AM

@pan64 since this happened with some large database of files containing thousands of files, I found it difficult to learn it by looking through the file list. Creating a separate trial db was more work without clarity at that point to ensure that it will reproduce the same behavior.

Thank you very much for the explaining the root cause Turbocapitalist, Aragorn2101, and rknichols.

Yes, rknichols .. I actually meant "*.jpg"

Thanks once again!