On Fri, Mar 12, 1999 at 12:13:57AM -0800, Daniel Quinlan wrote: > Actually, it's the other way around. /etc/cron.d requires you to > understand the crontab format. /etc/cron.<period> just requires you > to plop a shell script into a directory.
crontab's format is not that complicated. The argument has also been made that anacron enables users/administrators to configure shell scripts - if you take this position, my response is that shell script syntax is far more complex than the crontab format. > > No. What is the rationale? Vixie cron works just fine, except, > > perhaps that it assumes a box is up 24x7. If a box isn't up 24x7, > > why is it so critical to specify anacron? > > The box may not be up 24x7. We may want to provide a way for cron > jobs to work on boxes that aren't up 24 hours a day. Agreed. I was looking at it from the point of view of a server, which is up 24x7, and thinking that a user box is not as critical - I'm sure the user would think otherwise. :-) > > Leading with my chin, I ask "Have emerged as de-facto Linux standards"? > > for whom? News to me. > > I meant /etc/cron.(daily|weekly|monthly) was a standard, not cron.d. And that's what I was questioning. A quick look at the Linux systems I use and to which I have access don't have anacron or it's directories. The argument about following current usage or specifying something different has been raised before, though, and I don't want to start it up again. > > Noted and agreed. Is there any value in stating that non-cron-type > > schedulers should leave /etc/cron.d alone? > > Well, then they would be violating the LSB specification, wouldn't > they? (We can specify that the cron software must handle things as > specified by the cron manuals.) Mis-read that paragraph. -- Kurt Informix on Linux FAQ => http://www.xmission.com/~kwall
