The following reply was made to PR system/6462; it has been noted by GNATS.
From: Tim Chase <[email protected]> To: [email protected] Cc: [email protected] Subject: Re: system/6462: find(1) -print wtf [non-bug] Date: Thu, 09 Sep 2010 21:37:51 -0500 On 09/09/10 20:37, [email protected] wrote: > [...@fuyu xxx]$ touch foo.orig > [...@fuyu xxx]$ touch foo.rej > [...@fuyu xxx]$ find . -type f -name \*.orig -or -name \*.rej > ./foo.orig > ./foo.rej > [...@fuyu xxx]$ find . -type f -name \*.orig -or -name \*.rej -print > ./foo.rej Not a bug, but rather order of operations & short-circuit logic evaluation. Be explicit: $ mkdir f; cd f $ touch foo.{rej,orig} $ mkdir baz.{rej,orig} $ find . -type f -name \*.orig -or -name \*.rej -print ./foo.rej ./baz.rej $ find . -type f \( -name \*.orig -or -name \*.rej \) -print ./foo.orig ./foo.rej or even just $ find . -type f \( -name \*.orig -or -name \*.rej \) ./foo.orig ./foo.rej From the man page's help on "-or": "The second expression is not evaluated if the first expression is true." The second expression contains the "-print" since the "-or" has the lowest precedence. Also note that the if no other action is assumed, "the given expression is effectively replaced by ( given expression ) -print" so there's no need for the redundancy. (FYI, my understanding is that "-or" isn't POSIX compliant, while "-o" is; though most versions of find seem to accept "-or") -tkc
