On Mar 17, 2004, at 8:31 pm, Our Pal Al wrote: > Hmmmm ... I think we're getting there. And I can even follow this! :) > > Problems though ... > > On 3/17/04 12:07 PM, "Stroller" <MacMonster at myrealbox.com> wrote: >> >> This seems close to what you require, although I can't immediately >> seem >> to see how to drop the leading zero, short of using sed. >> >> $ date >> Wed Mar 17 17:00:11 GMT 2004 >> $ let "one_week_ago = `date +%s` - 60 * 60 * 24 * 7"; date -r > > Trying this out in a term window, I copy and paste this into my bash > shell > and it doesn't work. Error - > > "date: option requires an argument -- r > usage: date [-nu] [-r seconds] [+format] > date [[[[[cc]yy]mm]dd]hh]mm[.ss] " That's because you missed out the "$one_week_ago +%m/%e/%Y" arguments to the 2nd date command. one_week_ago is a variable, which you assign with `one_week_ago = 12345` and read with (say) `echo $one_week_ago` > Is this is something that'll only work in a script? No. I used the first $ (one a new line, with a space following it) to indicate I can it at the CLI. I haven't encountered anything that'll run in a script but give problems at the CLI. > Bear with me. All my > shell scripting needs have been simple so far and there's been nothing > I've > made that I couldn't test out line by line first, then just "sew 'em > all > together" in a script. Well, I'm not sure why you didn't do this. That's what I had to do when I built it for you. For instance: $ date +%m/%e/%Y 03/17/2004 $ date +%s 1079559134 $ let "foo = `date +%s` - 10000000" $ date -r $foo Sun Nov 23 03:50:16 GMT 2003 $ let "foo = `date +%s` - 1000000000" $ date -r $foo Sun Jul 9 20:51:15 BST 1972 I've already directed you to `man date` and `man strftime` - next time you post you need to quote the parts of those which you don't understand. *sighs* Ok... here you go... -r Print out the date and time that is seconds from the Epoch. %s is replaced by the number of seconds since the Epoch, UTC (see mktime(3)). Since we can easily calculate the number of seconds in the last week (60 * 60 * 24 * 7), "seconds since the epoch" (I just call this "Unix time") and easily manipulate bif decimal numbers, this is the way to go. `date +%s` prints out the time NOW in seconds since 1970, so we subtract 604800 from that to get One Week Ago. The `date -r some_number` converts some_number of seconds since 1970 into a Real Date (tm). `date +%m/%e/%Y` prints out today's date in that dumb American format, in which months, days and years are in haphazard order. > On 3/17/04 12:18 PM, "Stroller" <MacMonster at myrealbox.com> wrote: > >> And having wasted all that time on an answer involving long date >> formats, I think the answer is really a weekly `cron` job to >> mv Restrospect\ backup\ report Restrospect\ backup\ report-`date >> +%Y-%m-%d_%X >> and run your grep on the new one that's subsequently created by the >> new >> backup. > > Hmmm ... I don't think that will work. > > Retrospect's exported Backup Report will give me a bigger file every > day > with everything going back for months and months, new things not even > added > to the top! So you're saying that if you delete that file, then next time you come back it will have recreate the whole several months' of reporting..? I would have anticipated that it would start a fresh file with only current reports, in which case you could copy the old file into a new filename, delete the filename that Retrospect appends it's data to (I mean, if it doesn't appear at the top, presumably it appears at the bottom..?) and then your grep will only act on that new data when that file is recreated. But I'm not familiar with Retrospect. > This is separate from the log. The log is display only and > presented in a window - which I can truncate to an arbitary k limit, > chopping off events too old mid-entry, will-nilly, which isn't really > my > preference as I outlined in an earlier post. I would be rather surprised to find that log exists ONLY in a window and not somewhere on your hard-drive. In which case it IS possible to manipulate it. Moving last week's log from log.current to log.old.20040310 is NOT the same as "deleting stuff willy-nilly". If your software does not save an *incremental* log (meaning a log to which data is appended (at the end) line-by-line as events occur) to file, then really it's not very good software. > So if I every day grep the file for that day's events, I will in 7 > days have > created a file that goes back a week. And then the next day will go > back a > week and a day. Etc, etc. So move the old data out of the file before you grep it. > To consistenly have a file that always has a week's worth of events, > I'll > still need to at some point have some date-aware contruct which can > age out > old events, not just lop off at a file size, and that brings us back > to the > start of this thread. `mv logfile last_weeks_logfile` is age-aware - it lops off all entries before this moment. You can run it via a `cron` job. Stroller.