> Why not just put the /etc/cron.daily|weekly|monthly tables into > /etc/cron.d, too? What does this buy the spec? Or the user, for > that matter? Drop it all into cron.d and you look one place and one > place only. It seems simpler.
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. > 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. > 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. However, I think you'll find that most, if not all, of the distributions like the cron.d extension. > 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.) - Dan
