Re: small side issue with find

[Greg Wooledge]

On Thu, Nov 04, 2021 at 12:35:05PM +0100, ikhxcsz7y xmbott wrote:
> i can at most show the script that i rewrote then with gawk grep -v style

Your attachment had type application/octet-stream which is really
inconvenient... oh well.

Here are the relevant lines from your script:

ex=( -name libTag -prune )
find=( find "${target[@]}" "${ex[@]}" -o -iname )
"${find[@]}" \*."$e"

In other words, you are running a command of this form:

find . -name libTag -prune -o -iname something

Is that really so hard for you to just *say*?  Sheesh.

Here's the result of your command:

unicorn:~$ mkdir /tmp/x
unicorn:~$ cd /tmp/x
unicorn:/tmp/x$ mkdir good libTag
unicorn:/tmp/x$ touch good/file1 libTag/file2
unicorn:/tmp/x$ find . -name libTag -prune -o -iname 'file*'
./libTag
./good/file1

Here's the result of the correct find command:

unicorn:/tmp/x$ find . -name libTag -prune -o -iname 'file*' -print
./good/file1

Now, you may be asking: "Why do I need the -print on the end?  Isn't
that the default action?"

It's difficult to find a nice, simple explanation for this.  Here's my
attempt to explain it, which may or may not be 100% accurate.

If you omit the -print in this command, find assumes that you wanted
this:

find . \( -name libTag -prune -o -iname 'file*' \) -print

Here's what that does in my example setup:

unicorn:/tmp/x$ find . \( -name libTag -prune -o -iname 'file*' \) -print 
./libTag
./good/file1

Looks exactly like what you didn't want, eh?

Instead, you only wanted to -print the files that match the condition
on the right-hand-side of the -o.  Thus, you need to put the explicit
-print *there*.  Don't let find assume what you wanted.