Re: Historical origin of cron's day-of-month/weekday behavior?
I emailed Brian about it last night, and found out that he didn't have anything to do with cron, despite the Wikipedia articles that credit him with it. He pointed me to Ken Thompson and Doug McIlroy as possible authors. Ken tells me that the behavior I expected was exactly how his original cron behaved, and he speculated that the current "buggy" behavior, as he put it, must have been introduced later. I first ran across the problem when I was new to UNIX. and it happened on a machine running BSD 4.1. Now that I think of it, every system I've tried it on since then has probably been derived from BSD in one way or another; I expect even Paul Vixie's version was modeled on the BSD cron's behavior, as the bug is clearly documented in the man page as an expected behavior. On Wed, Oct 19, 2011 at 8:38 AM, Jerry Feldman wrote: > Another issue is that it is virtually impossible to schedule something > every two weeks. We have a license that expires biweekly. After looking > at a lot of solutions, I decided to simply download it weekly. I think > in terms of the original AT&T cron, like other Unix tools they were > designed for use internally at Bell Labs. And, at the time, the > computers it ran on were rather underpowered, such as PDP 11s. As far as > Paul is concerned I remember him as the firewall guru at DEC West. > > On 10/19/2011 12:10 AM, John Abreau wrote: >> Yes, I know it's a limitation of cron, and that's precisely because >> the weekday field does not get ANDed like the other fields. >> >> If the weekday field *was* ANDed with the other fields, it would be >> trivially easy to specify "third Wednesday: >> >> 0 3 15-21 * 3 /path/to/scipt.sh >> >> This would run at 3:00 AM on every day from the 15th to the >> 21st that happens to fall on a Wednesday. It's a 7-day span, >> so there will only be one Wednesday in the span, and that >> Wednesday would be the third Wednesday of the month. >> >> If Brian hadn't made the weekday field behave differently >> than the other four fields, then this would work fine. But he >> made an extra effort to code it differently, which breaks >> this use case. >> >> Since coding the weekday field differently would have taken >> extra time and effort, and it complicated a program written by >> a man whose core programming philosophy was to keep things >> as simple as possible, I'm led to assume that he must have >> had a reason to code it differently that overrode his inclination >> to keep the program simple and robust. >> >> As for Paul Vixie, he reimplemented cron to behave like the >> original AT&T cron. that Brian Kernighan wrote, so I wouldn't >> expect Paul to know Brian's thoughts on the matter. But Brian >> is still alive, as far as I know, so maybe I can track down his >> contact info and ask him directly. >> >> >> >> On Tue, Oct 18, 2011 at 11:50 PM, Ken D'Ambrosio wrote: >>> It strikes me that this is a limitation of cron, period -- specifically, the >>> lack of "nth occurrence of day of week" field. Which is why the paragraph >>> you >>> quoted ends "One can, however, achieve the desired result by adding a test >>> to >>> the command...", said test then being illustrated: >>> 0 4 8-14 * * test $(date +%u) -eq 6 && echo "2nd Saturday" >>> >>> The fact that he calls it out, with an example of a work-around, makes me >>> think >>> that the historical thinking is simple: there wasn't any. It was -- at >>> least >>> to Paul Vixie -- an edge case he hadn't considered when he came up with the >>> initial syntax for crontab, and couldn't gracefully retrofit. That being >>> said, >>> everything I just wrote is, obviously, supposition; you could ping Teh >>> Source >>> [sic]; I imagine he'd enjoy a query as to his rationale: >>> paul-at-vix-dot-com. >>> >>> -Ken >>> >>> On Tue, 18 Oct 2011 23:29:03 -0400 John Abreau wrote >>> My experience is exactly the opposite. I've never run into a situation you describe, but it would be trivially easy to specify it with two cron entries: one specifying Mondays, and the other specifying the first of the month. On the other hand, my "odd case" that you claim is not particularly useful is one that I see all the time. Pretty much every program I've ever seen for scheduling events includes this, cron being the most notable exception. For the few others that lacked it, I recall reading reviews in magazines like PC World giving them bad marks for leaving out the feature. This leads me to believe that I'm not the only person on the planet who finds this functionality particularly useful. If you want other examples other than my user group, my local chapter of Toastmasters meets on the first and third Tuesdays of every month. At my previous job, we had a monthly staff meeting on the fourth Friday of every month. Back when the Boston Computer Society still existed, pretty much every BCS SIG would meet once a month on th
Re: Historical origin of cron's day-of-month/weekday behavior?
Another issue is that it is virtually impossible to schedule something every two weeks. We have a license that expires biweekly. After looking at a lot of solutions, I decided to simply download it weekly. I think in terms of the original AT&T cron, like other Unix tools they were designed for use internally at Bell Labs. And, at the time, the computers it ran on were rather underpowered, such as PDP 11s. As far as Paul is concerned I remember him as the firewall guru at DEC West. On 10/19/2011 12:10 AM, John Abreau wrote: > Yes, I know it's a limitation of cron, and that's precisely because > the weekday field does not get ANDed like the other fields. > > If the weekday field *was* ANDed with the other fields, it would be > trivially easy to specify "third Wednesday: > > 0 3 15-21 * 3 /path/to/scipt.sh > > This would run at 3:00 AM on every day from the 15th to the > 21st that happens to fall on a Wednesday. It's a 7-day span, > so there will only be one Wednesday in the span, and that > Wednesday would be the third Wednesday of the month. > > If Brian hadn't made the weekday field behave differently > than the other four fields, then this would work fine. But he > made an extra effort to code it differently, which breaks > this use case. > > Since coding the weekday field differently would have taken > extra time and effort, and it complicated a program written by > a man whose core programming philosophy was to keep things > as simple as possible, I'm led to assume that he must have > had a reason to code it differently that overrode his inclination > to keep the program simple and robust. > > As for Paul Vixie, he reimplemented cron to behave like the > original AT&T cron. that Brian Kernighan wrote, so I wouldn't > expect Paul to know Brian's thoughts on the matter. But Brian > is still alive, as far as I know, so maybe I can track down his > contact info and ask him directly. > > > > On Tue, Oct 18, 2011 at 11:50 PM, Ken D'Ambrosio wrote: >> It strikes me that this is a limitation of cron, period -- specifically, the >> lack of "nth occurrence of day of week" field. Which is why the paragraph >> you >> quoted ends "One can, however, achieve the desired result by adding a test to >> the command...", said test then being illustrated: >> 0 4 8-14 * *test $(date +%u) -eq 6 && echo "2nd Saturday" >> >> The fact that he calls it out, with an example of a work-around, makes me >> think >> that the historical thinking is simple: there wasn't any. It was -- at least >> to Paul Vixie -- an edge case he hadn't considered when he came up with the >> initial syntax for crontab, and couldn't gracefully retrofit. That being >> said, >> everything I just wrote is, obviously, supposition; you could ping Teh Source >> [sic]; I imagine he'd enjoy a query as to his rationale: paul-at-vix-dot-com. >> >> -Ken >> >> On Tue, 18 Oct 2011 23:29:03 -0400 John Abreau wrote >> >>> My experience is exactly the opposite. I've never run into a situation >>> you describe, but it would be trivially easy to specify it with two >>> cron entries: one specifying Mondays, and the other specifying >>> the first of the month. >>> >>> On the other hand, my "odd case" that you claim is not particularly >>> useful is one that I see all the time. Pretty much every program I've >>> ever seen for scheduling events includes this, cron being the >>> most notable exception. For the few others that lacked it, I recall >>> reading reviews in magazines like PC World giving them bad marks >>> for leaving out the feature. This leads me to believe that I'm not the >>> only person on the planet who finds this functionality particularly useful. >>> >>> If you want other examples other than my user group, my local >>> chapter of Toastmasters meets on the first and third Tuesdays >>> of every month. At my previous job, we had a monthly staff meeting >>> on the fourth Friday of every month. Back when the Boston Computer >>> Society still existed, pretty much every BCS SIG would meet once a >>> month on the n'th $WEEKDAY of the month. Doesn't GNHLUG >>> also schedule its meetings in this manner? >>> >>> In any case, my question was about the original author's reasoning. >>> I've poked around a bit more and learned that Brian Kernighan >>> was the original author, but I still haven't found anything where >>> he explains why he chose that behavior. >>> >>> Did you read somewhere that your use case was actually what >>> Brian had in mind? If so, can you share a link to the article >>> or point me to the book or magazine issue that you read it in? >>> >>> >>> >>> On Tue, Oct 18, 2011 at 10:45 PM, Ken D'Ambrosio wrote: Not trying to sound snooty, but this seems so obvious to me that I almost wonder if I'm missing the point. All the other fields deal with different units -- minutes, hours, months. day-of-month and weekday both apply to days; so, if you wanted something to execute on both Mondays *and* the first day
