hmm, on Tue, Apr 06, 2010 at 02:40:03PM +0200, Paul de Weerd said that
> What, really ?!
>
> The approach with a simple lookup table:
>
> PREVMONTH[1]="dec"; PREVMONTH[2]="jan"; PREVMONTH[3]="feb"
> PREVMONTH[4]="mar"; PREVMONTH[5]="apr"; PREVMONTH[6]="may"
> PREVMONTH[7]="jun"; PREVMONTH[8]="jul"; PREVMONTH[9]="aug"
> PREVMONTH[10]="sep"; PREVMONTH[11]="oct"; PREVMONTH[12]="nov"
>
> echo ${PREVMONTH[`date +%m`]}
>
> Or, if you are certain you're within the first day of the new month
> (as for 0 0 1 * * crons), `date -r $(($(date +%s) - 24*3600)) +%m`
> (adjust for 'first week of new month' etc .. or get fancy and find the
> number of days you've spent in the current month and go back that many
> plus one).
>
> Come on man .. 'can of worms' ?! It's not even a real challenge.
you left off the year...
i'd rather not bloat my 3 line scripts with lookup tables
and recursive date(1) calls, i prefer them easy and short.
here's the full picture of the current situation:
on 1. april i get this file through monthly.local:
logfile-2010-04.log.gz
containing all _march_ entries (plus some april if it creeped in).
i have 2 choices:
1. do the rename dance backwards one month
2. let the job actually run sometimes before midnight, last day of the month.
newsyslog can do it. cron can't.
regarding the "forward casualties" of log rotation, yes it's the same.
while chronologically i still prefer the other way, i.e. have older
entries in the newer log file (and not newer entries in older logfiles),
but the main issue is, that i end up with the wrong file name.
-f
--
what follows 2 days of rain? -- monday
