Bash 'find' bug

Also if the path fails to match I get an error at the terminal. Not very good for subsequent use in a plist as it will fill logs with silly messages.

You can kill error messages with

find /path/to/file/or/dir -prune ...other...stuff... >/dev/null 2>&1

which will cause all output and errors to disappear.

Is there a better form of wording somewhere

Unix man pages are notorious for minimum wording as written by the developer who often does not fully utilize all the features of the command, not like the users in general. If a man page has an example, you are lucky. Many times it is not what a man page say, it is what it doesn't say and reading between the lines.

And on 'find' is one of the much more complex and powerful commands that has had lots of different developers sticking their fingers into it many only understanding the small part they added because they wanted it, and not the other parts.

I've been using 'find' since '85 and except for simple searches, I have to read the man page, and then experiment, experiment, experiment to make sure I got the command right.

So no, I do not know of any better wording. I only know about experimentation and previous experience.

Not quite as good as I thought. I get a 'true' if the path matches even if subsequent criteria fail to match. I would have liked a true only if all conditions are fulfilled.

Is there a reason you need to know if the file/directory exists, but it does not match all the selection information? Did you want to do something to a file that does not match all the selectiion items? Would this be something that you could get 'find' to actually select if you included things like ! -xxxx which will invert the true/false value of the operator. Many of the numeric arguments can have + or - to select greater or less than the numeric value. If you get the selection operators to ignore files/directories you do not want to mess with, and only select files you need to do something with, would that be good enough?

There are other ways to do things you want. You can use a 'find' command to make a partial selection, and then use additional command to make a final decision

find "/path/to/file/or/directory" -xxxx -yyyy | while read file
do
    find "$file" -qqqq -rrrr -ssss | while read another
    do
        ...do something else... which could be any other Unix command
    done
done

There are a whole host of bash shell conditional that can be used against individual files

if [[ -d /path ]]; then
   echo this is a directory
fi

[[ -x /path ]] && echo this file has the executable bit set

[[ ! -s /path ]] && echo this file is empty

[[ /path1 -nt /path2 ]] && echo path1 is newer than path2

[[ /path1 -ef /path2 ]] && echo path1 and path2 are the same file even if the names are different

exactly what you are trying to do, and what things you need to test for would help others suggest solutions.

OK. Some suggestions

For "Untitled Folder" selection, use something like -Bmin -1 which will select any Untitled Folder found that is less than a minute old.

If you are worried about the folder being empty or almost empty (just has a .DS_Store), you could find new Untitled Folders, then do a sanity check on the inside. For example, the following bash (must be bash) code might do what you want:

TOTALLY_EMPTY_FOUND=0
EMPTY_WITH_DS_STORE_FOUND=0

while read name
do
    if [[ $(ls -a "${name}" | wc -l) -eq 2 ]]; then
        echo totally empty directory # put your special code here or call a function
        $((TOTALLY_EMPTY_FOUND++))
    fi

    if [[ $(ls -a "${name}" | wc -l) -eq 3 && -e "${name}/.DS_Store" ]]; then
        echo the directory ONLY has .DS_Store, but otherwise it is empty  # put your special code here or call a function
        $((EMPTY_WITH_DS_STORE_FOUND++))
    fi
done < <(find ~/Desktop/Untitled\ Folder* -prune -Bmin -1 >/dev/null 2>&1) # special bash trick

echo $TOTALLY_EMPTY_FOUND
echo $EMPTY_WITH_DS_STORE_FOUND

This would find empty or almost empty Untitled Folder's in the Desktop that were less than a minute old (that is the -Bmin -1 in action). It would not complain if it didn't find anything (the >/dev/null 2>&1 at work). It would allow you to do special processing when it found an empty folder or an empty folder with just a .DS_Store. It increments counters so that after the loop ends you can see if the loop found anything (this is where the speical bash < <(command) process redirection feature comes in which makes sure that while loop runs in the current shell context and the 'find' command runs in a sub-process (your typical "find | while" loop syntax puts the 'while' loop in a sub-process and any variables set in that sub-process are not seen by the current shell context, where as the "while ... do ... done < <(find)" notation keeps the "while" loop in the current shell context and all variables set are visible after the loop ends).

You can of course tailor this to your needs, assuming it even comes close to your needs.