(Duplicated from Stack Overflow: https://stackoverflow.com/questions/7854975/how-to-exclude-a-list-of-full-directory-paths-in-find-command-on-solaris)
I have a very specific need to find unowned files and directories in Solaris using a script, and need to be able to exclude full directory paths from the find because they contain potentially thousands of unowned files (and it's normal because they are files hosted on other servers). I don't even want find to search in those directories as it will hang the server (cpu spiking to 99% for a long time), therefore piping the find results in egrep to filter out those directories is not an option.
I know I can do this to exclude one of more directories by name:
find / -mount -local \( -type d -a \( -name dir1 -o -name dir2 -o dir3 \) \) -prune -o \( -nouser -o -nogroup \) -print
However, this will match dir1 and dir2 anywhere in the directory structure of any directories, which is not what I want at all.
I want to be able to prevent find from even searching in the following directories (as an example):
/opt/dir1
/opt/dir2
/var/dir3/dir4
And I still want it to find unowned files and directories in the following directories:
/opt/somedir/dir1
/var/dir2
/home/user1/dir1
I have tried using regex in the -name arguments, but since find only matches 'name' against the basename of what it finds, I can't specify a path. Unfortunately, Solaris's find does not support GNU find options such as -wholename or -path, so I'm kind of screwed.
My goal would be to have a script with the following syntax:
script.sh "/path/to/dir1,/path/to/dir2,/path/to/dir3"
How could I do that using find and standard sh scripting (/bin/sh) on Solaris (5.8 and up)?
find
do not support-path
test, you can simulate it using-exec test "{}" = "/path/to/exclude" \; -prune
. The{}
should be expanded to full path name.find / -mount \( -type d -a \( -exec test "{}" = /dev \; -o -exec test "{}" = "/proc" \; -o -exec test "{}" = "/tmp/test" \; \) \) -prune -o \( -nouser -o -nogroup \) -print
It worked, but it took a lot more time to run. I was monitoring CPU usage while the find was running and it was not going over 27%, which is not so bad, but I only have 3 tests in my condition. I wonder how bad it would get when there's more...