HP3000-L Archives

April 2003, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tom Emerson <[log in to unmask]>
Reply To:
Tom Emerson <[log in to unmask]>
Date:
Mon, 21 Apr 2003 16:32:25 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
 [seems the list doesn't like my e-mail provider today (it isn't the only one
-- got a bounce from another list as well), so I'm posting via the
newsgroup.  OTOH, the news<-->e-mail link seems down as well so eventually
this may double post...]

On Monday 21 April 2003 13:23, Donna Garverick wrote:
>      39   :  run main.pub.vesoft;&
>      40   :    info="purge
> ./logs/access_log.@(credate<today-30);yes"
>
> is there a shell-ish way of doing the same thing i'm doing
> with mpex?             - d

I'm finding "find" is a close equivalent to MPEX's generic "file selection"
capability.  For dates & times, *nix provides access, modify, and "state
change" [whatever that means...]  These are referenced as amin/atime,
mmin/mtime, and cmin/ctime respectively.  the x"min" is in minutes while
x"time" is in "n*24 hours" [a fancy way of saying "days"]

In addition, you need to specify a + or - to get greater-than or less-than
functionality [and without a specifier, it means "exactly"]

To list the files you are after, I think this will work:

   find . -ctime +30 -daystart -name 'access_log*'

the "daystart" parameter normalizes things to midnight vs. "right this
second".  This list can be fed to the "rm" command like this:

   rm `find . -ctime +30 -daystart -name 'access_log*'`

note that the find command and parameters are surrounded by "back-quotes"
[usually left of the number 1 on the top row]

Note also that "c" is "file status changed", not neccesarilly "file was
created" -- I believe changing something like ownership or ACL type info
counts as a "status change", but 99% of the time this will work out "ok"
[and
in this case, the 1% where it fails will just leave an extra file around for
a few days]

I'm also finding find to be finicky -- any niggling mistake and "find"
returns
nothing at all, which may be ok, but in some cases "nothing" defaults to
"everything" for the command issued against it -- for instance:

   ls `find . -false`

acts as if you just type "ls", which will display everything...
--
Yet another blog: http://osnut.homelinux.net

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

ATOM RSS1 RSS2