charles@c3pe.UUCP (Charles Green) (08/18/89)
I'd like to run a program on, say, the second Tuesday of each month. I thought 10 20 8-14 * 2 command would be a sufficient specification, since the only time that a logical 'and of all fields is satisfied is at 20:10 on a Tuesday between the 8th and 14th, inclusive; i.e., the second Tuesday. However, it appears that the logical 'or' of the day-of-week and day-of-month fields is being taken, instead; i.e., 'command' gets run on each of the days between the 8th and the 14th and, probably, on every Tuesday besides. One of my UNIX manuals bears this out. I've checked this out on two different systems (a Masscomp running 4.0A and a Convergent MightyFrame running 5.22) and get the same results. Can someone tell me if there's a way to specify the desired action, short of having 'cron' run a script which first checks the date to determine validity, *then* does the command? Thanks, Charles Green charles%c3pe@decuac.dec.com -- {decuac.dec.com,cucstud,sundc}!c3pe!charles ex::!echo Boo:
davidsen@sungod.crd.ge.com (ody) (08/22/89)
The implementation of cron is really stupid! They could have allowed both day of week and day of month with two lines and then anded the day of week/month fields to do what you want. However, you can get what you want at low cost by running a script every Tuesday and checking the date, as: set `date` if test $3 -lt 8 -o $3 -gt 14; then exit 0; fi # Now do what you really wanted Thanks for pointing this out, I always assumed that the crontab worked in the logical way. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
debra@alice.UUCP (Paul De Bra) (08/23/89)
In article <1794@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >The implementation of cron is really stupid! They could have allowed >both day of week and day of month with two lines and then anded the day >of week/month fields to do what you want. > The implementation that takes the "or" of day of month and day of week is not just stupid, it is wrong. The manual page (ninth edition unix) has an example: daemon 0 12 22-28 11 4 mail turkey % time's up: thanksgiving dinner I haven't checked whether this actually works, but it's clear that the intention is to have it work. Furthermore the manual says that: "an asterisk means all legal values", so an entry 0 0 1 1 * under the "or" interpretation would mean execute this at midnight, in january, on the first or on any day of the week, which would imply that the line is executed every single day in january. It is clear that this is NOT done by any implementation of cron I know of. So the behaviour for * actually implies that cron should NOT take the "or" of the day of month and day of week. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/24/89)
In article <9805@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > In article <1794@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > >The implementation of cron is really stupid! They could have allowed > >both day of week and day of month with two lines and then anded the day > >of week/month fields to do what you want. > > > > The implementation that takes the "or" of day of month and day of week > is not just stupid, it is wrong. Well, if functioning just as the man page indicates it should is wrong, then it is. However, I always figured that if it worked as documented it was correct. Here's an exerpt from the man page: Note that the specification of days may be made by two fields (day of the month and day of the week). If both are specified as a list of elements, both are adhered to. For example, 0 0 1,15 * 1 would run a command on the first and fifteenth of each month, as well as on every Monday. To specify days by only one field, the other field should be set to * (for example, 0 0 * * 1 would run a command only on Mondays). It doesn't work the way I thought it did, or even the way I think is *should*, but it works as documented.