greywolf@unisoft.UUCP (The Grey Wolf) (03/27/91)
/* * discussion re: finding all files modified today. * subdebate regarding performance of test unless it's a shell builtin... */ One way to accomplish finding all files modified today is to go by a timestamp file which was touched at midnight, and use "find . -newer <timestampfile> -print | xargs /bin/ls -<lsopts>..." or whatever is most optimal. I think find(1) needs yet more improvement, most of all in the department of time granularity (if you can call a day "granular" -- seems like a large boulder to me...). Oh, and a -ctime option would be nice...
les@chinet.chi.il.us (Leslie Mikesell) (03/28/91)
In article <3450@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >One way to accomplish finding all files modified today is to go by a >timestamp file which was touched at midnight, and use >"find . -newer <timestampfile> -print | xargs /bin/ls -<lsopts>..." >or whatever is most optimal. >I think find(1) needs yet more improvement, most of all in the department >of time granularity (if you can call a day "granular" -- seems like a large >boulder to me...). Oh, and a -ctime option would be nice... Huh? -newer works down to the second so the granularity is limited to however often you touch the checkpoint file. The -ctime and -mtime and -atime options work on day granularity though (i.e. +days or -days). There is a problem in maintaining atime and ctime unless you do backups with a read-only mount. Using cpio you have a choice of letting it modify the access time or not. If you let it fix the access time, then it will modify the ctime instead as a side effect. The real problem with find is that it always wants to recurse and (at least with the SysV versions) there is no way to limit it to the current directory. Les Mikesell les@chinet.chi.il.us
jay@silence.princeton.nj.us (Jay Plett) (03/28/91)
In article <3450@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes: > I think find(1) needs yet more improvement, most of all in the department > of time granularity (if you can call a day "granular" -- seems like a large > boulder to me...). Oh, and a -ctime option would be nice... -ctime is available in at least Sun's and gnu's find. I have added several primitives to gnu find and sent the sources off to gnu. If gnu likes them, they should be available in a future release. -amin n File was last accessed n minutes ago. -anewer file File's access time is more recent than the modification time of file. -anewer is affected by -follow only if -follow comes before -anewer on the command line. -cmin n File's status was last modified n minutes ago. -cnewer file File's status was last changed more recently than the modification time of file. -cnewer is affected by -follow only if -follow comes before -cnewer on the command line. -gid n File's gid matches n. -lname pattern File is a symbolic link and its object matches glob pattern pattern. The entire object string is compared with pattern, not just its basename. For example, in ``foo -> ./bar', -lname bar would not match but -lname '*bar' would. Slashes have no special meaning. -mmin n File was last modified n minutes ago. -uid n File's uid matches n. -used n File was last accessed n days after its status was last changed. -plink True if file is a symbolic link, else false. Print file's name and its link object as ``name -> object''. To print all names, resolving symbolic links, use ``- plink -o -print''. --- Jay Plett jay@princeton.edu
merlyn@iwarp.intel.com (Randal L. Schwartz) (03/30/91)
In article <686@silence.princeton.nj.us>, jay@silence (Jay Plett) writes: | I have added several primitives to gnu find and sent the sources off | to gnu. If gnu likes them, they should be available in a future | release. [...] | -gid n | File's gid matches n. [...] | -uid n | File's uid matches n. Whoa! You mean that GNU find doesn't implement the standard -user and -group, which handle numeric IDs just fine? (Or have I been playing with a non-V7 find for too long?) Just another UNIX hacker, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
jay@silence.princeton.nj.us (Jay Plett) (03/30/91)
In article <1991Mar29.185347.6657@iwarp.intel.com>, merlyn@iwarp.intel.com (Randal L. Schwartz) writes: < In article <686@silence.princeton.nj.us>, jay@silence (Jay Plett) writes: < | I have added several primitives to gnu find and sent the sources off < | to gnu. If gnu likes them, they should be available in a future < | release. < [...] < | -gid n < | File's gid matches n. < [...] < | -uid n < | File's uid matches n. < < Whoa! You mean that GNU find doesn't implement the standard -user and < -group, which handle numeric IDs just fine? (Or have I been playing < with a non-V7 find for too long?) Thanks for posting the question. I've had several private e-mails asking the same question, but was too shy to post an unprovoked followup :-). gnu find, like all the others, has -user and -group and they can handle numeric [ug]ids. But `n' has a specific defined meaning in the find documentation: Numeric arguments can be specified as +n for greater than n, -n for less than n, n for exactly n. Thus: find . -uid +100 -print for example, lists those files owned by a uid > 100. This is a different facility than that provided by "-user _uid_". ...jay
guy@auspex.auspex.com (Guy Harris) (03/31/91)
>Oh, and a -ctime option would be nice...
Then get the S5 (R3, possibly earlier) "find", or the 4.3-reno "find",
or a "find" derived from one or the other; they both have "-ctime".