Tag!  You're it!  ;)

At -0700 09:28 AM 4/22/2003, Donna Garverick replied to my reply to her:
>>  1. Simplest(?) solution, but may fail if the command buffer overflows
>> due to many matching files and/or long paths:
>>  $ rm $(find ./logs -name 'access_log.*' -ctime +30)
>
>command buffer overflows??

The MPE CI has (unless it's been changed in the last several years) a
command line buffer of about 280(?) characters.  Longer lines than that
return an error.  Likewise the shell has a maximum command line buffer
size.  It's much larger than a few hundred bytes, something like 8K or
maybe 64K or even more.  Don't know and don't really care.  But it's not
infinite.  For example:

$ echo $(find /) |wc

[Hang on while I go try it on Linux and MPE/iX.]

Wow!  I expected that to fail on my SuSE7.3 Linux system with an error
because that's trying invoke echo with the full pathname of every file on
the system as an argument.  Astonishingly, that worked!  I got back "1
221371 10804023" (where the three values are #lines #words #bytes,
respectively).  In other words, the "echo" process apparently was created
with 221371 arguments totalling over 10MB.  (And it ran all of that in less
than 5 seconds on a single-processor 1.0GHz P3 with IDE disc drives.  I
don't know if it works on MPE because after pegging an [effectively 58MHz]
A400-110 CPU at 90% for most of an hour I killed it.  Maybe I'll try again
overnight to see what happens.)

>>2. For *each* matching file, print the path and then invoke rm to delete it:
>>$ find ./logs -name 'access_log.*' -ctime +30 -print  -exec rm {} \;
>>
>>3. For *each* matching file, echo a prettier message and then delete it:
>>$ find ./logs -name 'access_log.*' -ctime +30 -exec echo Deleting: {} \;
>>-exec rm {} \;
>>
>>4. Pipe filenames to xargs which will prevent buffer overflow by invoking
>>rm (only) as many times as needed:
>>$ find ./logs -name 'access_log.*' -ctime +30 |xargs rm
>>
>>5. Same flaws as example 1, but otherwise does the same as example 3 in
>>an easier to read manner:
>>$ for Z in $(find ./logs -name 'access_log.*' -ctime +30)
>> > do
>> > echo Deleting: ${Z}
>> > rm ${Z}
>> > done
>>
>>I'd probably use example 4, but 3 and 5 both have merit too.  All the
>>examples invoke "find" only once, but only example 1 invokes "rm" just once.
>
>(just playing devil's advocated...but...) why are you saying that rm is
>only invoked once for example #1?  (yes, i know the answer....i think,
>however, there are wondering minds out there...)

The $(...) syntax says to insert the output of whatever is inside the
$(...) into the command line and then execute it just as is all that had
been typed.  So if the command "find ." returns "a b c" then "rm $(find .)"
would be just like typing "rm a b c".   The "rm" process is created only
once and passed the three file names to delete.

>>All the other examples invoke "rm" (and where present "echo") once for
>>each file.  Example 4 invokes "xargs" once and "rm" as few times as
>>feasible (probably just once) passing multiple filenames to each invocation.
>>
>>Note the "invoke" above means "fork and exec", which means "create a new
>>process".  Unless you know the number of files will be small and/or you
>>don't care about performance issues, examples 2, 3 and 5 may be ill-advised.
>
>in this particular case, there are very few files to purge.

Then you are probably safe in picking whichever method suits your fancy.  :)

>>I haven't tested most of these so there may be typos or other flaws.  I
>>suggest you experiment with the above replacing "rm" with "echo would
>>remove" or "echo ls -ldc" to see what happens.

Oops.  The "echo ls -ldc" was meant to be simply "ls -ldc".

>i looked at find's man text....and found the descriptions for ctime, mtime
>and atime to be 'lacking' at best....different world....different rules, i
>guess.

At least it's not boring?  :)

>so in this 'different world' -- is there a more common way of handling the
>'build up' of log files?

Pretty much as shown above from what I've seen.  Unless it's done manually.  :D

>>And if "find" on MPE/iX supports "-daystart" you may want to add that.
>
>seems to me it does....

The manpage on an MPE/iX 7.0 here doesn't seem to document "-daystart".  I
didn't bother to try it.

--
Jeff  Woods
"You are going to see Windows and Linux absolutely eviscerate the midrange
proprietary Unix."--Michael Capellas, HP President, May 2, 2002

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *