I've run into a brick wall using the -prune command to avoid walking sub-directories. Does any one have any suggestions on how I avoid walking the sub-directories when finding files in the following example?

I want to find all files older than 30 days in the dir1 directory and only the dir1 directory.

Directory structure looks something like this, for example :
/dir1/dir2/dir3.....

Here's the find command that I'm using right now:

find /dir1 -prune -o -name '*' -mtime +30 -print > filelist.lst

However, I keep getting output for files located in the dir2 and dir3 directories as well. Any thoughts on how to keep this find command from walking the sub-directories?

This has been answered many times. Here you go.

Performing a non-recursive find in Unix

i did see that solution but it does not work in my case. Here's what I had using that solution :

find /dir1 \( ! -name /dir1 -prune \) -name '*' -mtime +30 -print > filelist.lst

However, when I check the filelist.lst file it is empty and shouldn't be because there are files in /dir1 that are older than 30 days.

It seems to work for me on Solaris.

Try adding the -name '*' after the -prune portion of the command and see if you get any different results.

It's still working. But why are you passing that name parameter if your looking for a wildcard anyway? find will do that by default.

That's wierd because it won't work on HP-UX 11i. The -name '*' would be a passin value from user input. It could be '*' or '*TEST' or any other wildcarded search parameter. They can also input whether or not they want to search sub-directories for the input filename(s). I'm setting a flag for the sub-directory search to determine the appropriate find command structure to use based on their inputs. So, if they want to search sub-directories of the initial search path there is no issue because I don't need to use the -prune. However, if they don't want to search sub-directories underneath the initial search path AND they enter an '*" for the filename(s) to search for I run into this issue.

Based on your results this may well be a HP-UX issue. Although I'm not positive of that at this point.