using "find" without looking into subdirectories

[Marc Ahrendt]

How can I use the "find" command (if this even even the best appraoch) to search only in the present working directory /home/mahrendt for files newer than /tmp/frog but not to search in subdirectories of /home/mahrendt?

Below will not work for me:
cd /home/mahrendt
find . -type f -newer /tmp/frog -print

and from "man find" its seems that I could use "-prune" but have not been able to get that to work...

[John Guster]

cd to that directory
ls -lrt >/tmp/file.lst
vi /tmp/file.lst to find frog, then remove all above frog line, you get the list of files younger than frog. Hope it helps.

[James R. Ferguson · Accepted solution]

Hi Marc:

I have little luck with '-prune' on HP-UX's 'find'. Since you want to confine yourself to one directory level, you can do the following:

# cd /home/mahrendt
# ls -l|grep "^-"|while read X X X X X X X X FILE;do [ ${FILE} -nt /tmp/frog ] && echo ${FILE};done

This looks for regular files only and compares them to be newer ('-nt') or not to your "/tmp/frog" reference file.

Regards!

...JRF...

[Steven Schweda]

With GNU "find", it's simple:

dy # ls -lR
total 16
-rw-r--r-- 1 root sys 4 Oct 8 17:23 aaa
drwxr-xr-x 2 root sys 96 Oct 8 17:23 sub-dir

./sub-dir:
total 16
-rw-r--r-- 1 root sys 4 Oct 8 17:23 bbb

dy # /usr/local/bin/find . -maxdepth 1
.
./aaa
./sub-dir
dy # /usr/local/bin/find . -maxdepth 1 ! -type d
./aaa
dy #

http://www.gnu.org/software/findutils/

[Hein van den Heuvel]

It always amazed me how this seemingly simple find request is hard to do on hpux.

>> How can I use the "find" command (if this even even the best appraoch)

Whether it is the nest approache depends on what you want to do with the file, once you found it. The -exec options do not always allow to one to express things like renames.
So one ooften ends up just printing the names to re-read and do something with them.

Tools like perl could take immediate action.
Starting point:

perl -le '$ref = -M q(/tmp/frog); for $file (<*>) { print $file if -M $file < $ref }'

The <*> is a 'glob' function for all files. Ammend as desired.

The -M is fractional days since last modification.

And yes, perl has a file::find extention.
And no, it does not appear to have an easy maxdepth.

hth,
Hein.

[Dennis Handly]

>JRF: I have little luck with '-prune' on HP-UX's 'find'.

Right, we need better examples. :-(
This works if not too many files:
find * -type f -newer /tmp/frog -prune

[Marc Ahrendt]

John: Thanks for the response but I do not want such manual tasks for what I think should be able to be scripted as one task ...escpecially since I and others need to do this task often

James: Very helpful work-around to the "find" issue ...I used you code to get version 1 of my script working

Steve: The GNU "find" is exactly what I need ...just will have to incorporate it into a later/final version of my script (when I get to installing that program)

Hein: Your perl feedback was very helpful as it almost did what the code James posted ....except that it also listed the subdirectories. As you stated its a starting point, so most likely this will be in version 2 of my script because its perl ;)

Dennis: Thanks for the response but I never got "-prune" to work within a directory of 6 files and 1 subdirectory (having 2 files)

[Hein van den Heuvel]

>> Hein: Your perl feedback was very helpful as it almost did what the code James posted ....except that it also listed the subdirectories. As you stated its a starting point, so most likely this will be in version 2 of my script because its perl ;)

Excellent. Indeed I did not show how to test for 'normal file'.
In perl that is the -f operator/function.
By default it acts on the default variable $_.


perl -le '$ref = -M q(x.pl); for (<*>) { next unless -f; print if -M $_ < $ref }'

Cheers,
Hein.

[Laurent Menase]

find . \( -type f -o -name . -o -prune \) -type f -newer afile

[Marc Ahrendt]

Hein: Thanks again ...appreciate the extra feedback (it does the deal!)

Laurent: WOW, you addressed my initial hangup with "find"!! your options work perfectly and obviously "man find" made more sense to you than me ...can you explain/translate the command line options you used?

[Dennis Handly]

>I never got "-prune" to work within a directory of 6 files and 1 subdirectory

You need to use the "*". But Laurent's solution works better.

>you addressed my initial hangup with "find"!! your options work perfectly and obviously "man find" made more sense to you than me. Can you explain/translate the command line options you used?

Unfortunately this isn't obvious in the man page. I.e. it is useless to use -prune unless there is that OR involved. Basically it now seems obvious. ;-)

\( -type f -o -name . -o -prune \) ...

This says to return true if it is a file, or the name is "." OR -prune (which is always true). Then AND that with the rest of the options.

What the fine print is really saying is that if it is a file or it is ".", do NOT do the prune actions, so it will look into ".".

[OFC_EDM]

Find files older than a date (without going into sub-directories)

Example:
Find files in current directory (/loc/A) older than June 3rd 2008

1. Create reference file
touch -t 200806030000 /tmp/june3.ref

2 Run the command
find /loc/A/* -prune ! -type d ! -newer /tmp/june3.ref -exec ls {} \;

This has always worked for me regardless of the number of files. In your case simply my reference file /tmp/june3.ref with /tmp/frog and /loc/A with /home/mahrendt.

Cheers

[Laurent Menase]

Denis explained well, the options.
About:
find /loc/A/* -prune ...

The side effect is it doesn't show files begining with .
so better:
find /loc/A/* /loc/A/.?* ....


.?* can match with .. but .. -prune will stop at .. so it is ok too.

[Dennis Handly]

>Kevin: This has always worked for me regardless of the number of files.

This is an unhelpful statement. The correct statement is: I can see how using "*" would fail with zillions of files. The shell would have trouble expanding the command.

(I.e. first create a zillion files in your directory. :-)

[Marc Ahrendt]

Thanks Kevin/Dennis/Laurent for all the extra feedback ....very helpful

[OFC_EDM]

Dennis I don't have time to create a zillion files...I can't type that fast :)

But good point and I wonder if you'd know what would be the limitation of the find command I suggested? ...or a good guess anyways.

The command I provided is the one I use when other commands come up with "Arg list too long". And that find command has always been my fix....but when will it fail would be good to know.

Cheers

[Steven Schweda]

> [...] when will it fail would be good to
> know.

OS- and/or shell-dependent.

> And that find command has always been my
> fix.

A _good_ "find" command is one which does not
require the shell to expand a wildcard file
name specification. One of the primary
reasons to use "find" is to avoid a too-long
command line. Using "*" as a file spec in a
"find" command rather defeats that purpose,
making it not much of a "fix", in general.

[James R. Ferguson]

Hi:

> Kevin: But good point and I wonder if you'd know what would be the limitation of the find command I suggested?

It is the shell that expands your "*" and this leads to a too large (long) list of arguments that then can't be passed. To see this, simply do sompething like:

# cd /var/adm/sw && echo *

You can prevent the shell from expanding if you did:

# set -f
# cd /var/adm/sw && echo
# set +f #...reset normal behavior...

Now, to find out how large is the largest (limit), simply ask your system:

# getconf ARG_MAX
2048000

This is the maximum length of the arguments for exec() in bytes, including environment data.

Regards!

...JRF...

[OFC_EDM]

Thanks James for that explanation.
Too bad I don't own the thread or I'd assign points.

Cheers