1[ this is really old mail that came to me in response to my 1986 posting 2 to usenet asking for feature suggestions before releasing the first 3 version of cron. it is presented here for its entertainment value. 4 --vix ] 5 6From ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986 7Date: Wed, 31 Dec 86 08:59:31 pst 8From: lll-crg!ames!acornrc!bob (Bob Weissman) 9To: ptsfa!vixie!paul 10Status: RO 11 12Sure, here's a suggestion: I'd like to be able to run a program, say, 13every two hours. Current cron requires me to write 140,2,4,6,8,10,12,14,16,18,20,22 in the hours field. How about a notation 15to handle this more elegantly? 16 17<< Okay, I've allowed 0-22/2 as a means of handling this. 18 The time specification for my cron is as follows: 19 specification = range {"," range} 20 range = (start "-" finish ["/" step]) | single-unit 21 This allows "1,3,5-7", which the current cron doesn't (it won't 22 do a range inside a list), and handles your specific need. >> 23 24From drw@mit-eddie Wed Dec 31 18:25:27 1986 25Date: Wed, 31 Dec 86 14:28:19 est 26From: drw@mit-eddie (Dale Worley) 27To: mit-eddie!vixie!paul 28Status: RO 29 30We have a lot of lines in our crontab of the form 31 32 00 12 * * * su user < /usr/users/user/script.file 33 34This barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if 35user's shell is csh. This, I am told, is because csh requires that 36the environment be set up in certain ways, which cron doesn't do. 37(Actually, I believe, it is because /etc/rc, which runs cron, doesn't 38set up the environment enough for csh to run, and cron just inherits 39the situation.) Anyway, the point is that if you find out what csh 40really needs in its environment, you might want to set up cron to 41provide some reasonable defaults (if it isn't supplied by cron's 42parent). Also, could you tell me what csh needs, if you find out, so 43we can hack our /etc/rc? 44 45<< well, the environment IS a problem. processes that cron forks 46 will inherit the environment of the person who ran the cron 47 daemon... I plan to edit out such useless things as TERMCAP, 48 TERM, and the like; supply correct values for HOME, USER, CWD, 49 and whatever else comes to mind. I'll make sure csh works... >> 50From ptsfa!ames!seismo!dgis!generous Thu Jan 1 07:33:17 1987 51Date: Thu Jan 1 10:29:20 1987 52From: ames!seismo!dgis!generous (Curtis Generous) 53To: nike!ptsfa!vixie!paul 54Status: RO 55 56Paul: 57 58One of the limitations of the present versions of cron is the lack 59of the capability of specifying a way to execute a command every 60n units of time. 61 62Here is a good example: 63 64# Present method to start up uucico 6502,12,22,32,42,52 * * * * exec /usr/lib/uucp/uucico -r1 66 67# New method ?? (the ':' here is just one possibility for syntax) 6802:10 * * * * exec /usr/lib/uucp/uucico -r1 69 70This method would prove very helpful for those programs that get started 71every few minutes, making the entry long and not easily readable. The first 72number would specify the base time, and the second number the repetition 73interval. 74 75<< Good idea, but bob@acornrc beat you to it. I used '/' instead of 76 ':'. This is my personal preference, and seems intuitive when you 77 think of the divide operator in C... Does anyone have a preference? >> 78 79From ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan 1 17:04:24 1987 80From: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green) 81To: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul 82Date: Thu Jan 1 19:22:47 1987 83Status: RO 84 85Well, this isn't a compatible extension, but I have in times past wondered 86about a facility to let you start a process at intervals of, say, 17 minutes, 87instead of particular minutes out of each hour. 88 89<< This was a popular request! >> 90 91From seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan 4 13:04:01 1987 92Date: Fri, 2 Jan 87 09:23:53 cst 93From: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann) 94To: ptsfa!vixie!paul 95Status: RO 96 97I'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't 98figured it out ) but a comment feature would SURE BE NICE!. 99There are times when I want to comment out an entry 100for a period of time; it might also make it a lot more legible. 101 102<< My cron allows blank lines and standard #-type comments. I know 103 that one BSD4.2 cron I've used had it. I don't know about SysV. >> 104 105From ptsfa!hoptoad!hugh Mon Jan 5 10:26:46 1987 106Date: Mon, 5 Jan 87 01:22:17 PST 107From: hoptoad!hugh (Hugh Daniel) 108To: ptsfa!vixie!paul 109Status: RO 110 111 Hi, I do have a BIG one that I would like. I want to log ALL output 112from command lines into a file for each line. Thus I might have a chance 113of finding out why my crontab entry did not work. 114 This would seem to work best if done by cron, as it is now I have a google 115of shell scripts laying about just to put the error output where I can see 116it. 117 118<< My cron (and the SysV cron) will send mail to the owner of the 119 particular crontab file if a command generates any output on stdout 120 or stderr. This can be irritating, but if you write a script such 121 that any output means a problem occurred, you can avoid most logfile 122 needs, and not generate mail except in unforeseen circumstances. >> 123 124From ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan 5 13:08:46 1987 125From: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen 126Date: Fri, 2 Jan 87 14:25:29 EST 127To: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul 128Status: RO 129 130Here are some suggestions: 1311. Run it through the C preprocessor via "/lib/<whatever>". 132 133<< hmmm. this seems of limited utility, and if you really wanted 134 to do it that way, you could do it yourself (since users can 135 write to their own crontab files). I'll add '-' (read stdin) 136 to the crontab installer program to facilitate this. >> 137 1382. Allow specifying every Nth day of week, i.e., every second Wednesday. 139 I did this to calendar by separating the day of week (Wed=4, which one 140 to start on and N with slashes). I took modulo the day of year as a 141 starting point so that someone with a desk calendar documenting such 142 things can easily determine the offset (second number). I did this 143 while at SGI; alas I don't have a copy of the code. 144 145<< I can see how this could be useful, but I'm not sure how I'd 146 implement it. Cron currently doesn't keep track of the last time 147 a given command was run; whether the current Wednesday is the first 148 or second since the command was last run would be pretty hard to 149 figure out. I'd have to keep a database of commands and their 150 execution around, and purge it when the crontab was overwritten. 151 This is too much work for me, but if someone adds it, let me know. >> 152 153From ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan 6 05:50:17 1987 154From: ames!seismo!cbmvax!devon!paul 155To: cbmvax!seismo!nike!ptsfa!vixie!paul 156Date: Mon Jan 5 09:29:57 1987 157Status: RO 158 159One problem that has always plagued me with cron is the assumed ORing. 160I'd like to see some type of ANDing implemented. I guess I can best 161describe this by example. Say I have the following line in my crontab 162file: 163 164* * 4-31 * 1-6 /usr/bin/command 165 166What this does is run 'command' on the 4th thru 31st days of the 167month, AND on Monday thru Saturday; which probably means running it 168every day of the month (unless Sunday falls on days 1-3). This 169happens because cron runs the command if the day-of-month OR the 170day-of-week is true. 171 172What I'd like to happen with the above line is to run the command ONLY 173on Monday thru Saturday any time after the 3rd of the month, e.g. if 174the day-of-month AND the day-of-week are true. 175 176My proposal to you is to implement some special chars for the first 177five fields. Examples: 178 179* * !1-3 * 1-6 /usr/bin/command 180 181(run command Mon-Sat, but NOT [!] on the first 3 days of the month) 182 183* * &4-31 * &1-6 /usr/bin/command 184 185(run command if day-of-month AND day-of-week are true) 186 187Get the picture? This would be compatible with existing versions of 188cron (which wouldn't currently be using any special characters, so 189that old crontabs would be handled correctly). 190 191<< This message made me aware of the actual boolean expression involved 192 in a crontab entry. I'd assumed that it was 193 (minute && hour && DoM && month && DoW) 194 But it's really 195 (minute && hour && month && (DoM || DoW)) 196 197 I can see some value in changing this, but with a fixed order of 198 fields, operators get to be kindof unary, which && and || really 199 aren't. If someone has an idea on a syntax that allows useful 200 variations to the standard (&& && && (||)) default, please suggest. >> 201 202From bobkat!pedz Tue Jan 6 20:02:10 1987 203From: pedz@bobkat.UUCP (Pedz Thing) 204Date: 2 Jan 87 17:34:44 GMT 205Status: RO 206 207Log files! It would be nice to be able to specify a log for cron 208itself and also a log for each program's stdout and stderr to go to. 209The latter can of course be done with > and 2> but it would be nice if 210there could be a single line with some sort of pattern like 211`> /usr/spool/log/%' and the command would be substituted for the %. 212Another thing which would be nice is to be able to specify which shell 213to call to give the command to. 214 215<< Log files are done with mail. The '%' idea could be useful if 216 a different character were used (% is special to cron, see man 217 page); a different directory would have to be chosen, since each 218 user has their own crontab file; and something intelligent would 219 have to be done in the file naming, since the first word of the 220 command might be ambiguous (with other commands). In short, it's 221 too much work. Sorry. >> 222 223From guy%gorodish@sun Tue Jan 6 20:03:13 1987 224From: guy%gorodish@sun (Guy Harris) 225Message-ID: <10944@sun.uucp> 226Date: 5 Jan 87 12:09:09 GMT 227References: <429@vixie.UUCP> <359@bobkat.UUCP> 228Sender: news@sun.uucp 229Status: RO 230 231> Another thing which would be nice is to be able to specify which shell 232> to call to give the command to. 233 234Well, the obvious choice would be the user's shell, but this wouldn't work 235for accounts like "uucico". 236 237<< I use the owning user's shell, and to handle "uucico" I check a 238 list of "acceptable shells" (currently compiled in, does anybody 239 mind?), substituting a default (compiled in) shell if the user's 240 shell isn't on the list. 241 242 BTW, "compiled in" means that it's in a .h file, easily changed 243 during installation, but requiring recompilation to modify. You 244 don't have to go digging through the code to find it... >> 245 246From qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987 247To: hplabs!qantel!vixie!paul (Paul Vixie Esq) 248Date: 04 Jan 87 00:42:35 PST (Sun) 249From: Mike Meyer <mwm@violet.berkeley.edu> 250Status: RO 251 252<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>> 253 254Oh, yeah - here are the extensions on my cron: 255 2561) Sunday is both day 0 and day 7, so it complies with both SysV and 257BSD cron. 258 259<< Good idea. I did it too, thanks for informing me. >> 260 2612) At is integrated into the cron. Instead of atrun to scan the 262/usr/spool/at directory, at files are put into the /usr/lib/cron 263directory along with users cron files, and cron fabricates a line from 264a crontab file to run them. This is considered a major win by all who 265use it. 266 267<< I don't use 'at', and my cron doesn't do anything with it. To run 268 'at', I use 'atrun' the same way the current BSD cron does. My 269 crontab files are in /usr/spool/cron/crontabs, in the SysV 270 tradition -- not in /usr/lib/cron. This is a configuration 271 parameter, of course. >> 272 273There are two known restrictions: 274 2751) I don't support any of the SysV security hooks. I don't have a use 276for them, and RMS didn't like the idea at all :-). 277 278<< This means cron.allow and cron.deny. I plan to support them, as 279 they've been quite helpful at various HPUX sites I've administered. >> 280 2812) Cron expects to be able to create files with names longer than 14 282characters, which makes it hard to run on SysV. At least one person 283was working on a port, but I don't know how it's going. That might 284make for a good reason for releasing yours, right there. 285 286<< If someone has SysV (with the 14-character limit), they probably 287 won't want my cron, since it doesn't add much to the standard 288 version (which they may have support for). My cron is not currently 289 portable to non-BSD systems, since it relies on interval timers (I 290 needed to sleep for intervals more granular than seconds alone would 291 allow). The port would be trivial, and I will do it if a lot of 292 people ask for it... >> 293 294Oh, yeah - I'm going to see about getting this cron integrated into 295the next 4BSD release. 296 297<< How does one go about this? I have a few nifty gadgets I'd like 298 to contribute, this cron being one of them... >> 299 300<<[more FSF/GNU discussion deleted]>> 301 302From qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987 303Posted-Date: Fri, 2 Jan 87 19:26:16 est 304Date: Fri, 2 Jan 87 19:26:16 est 305From: hplabs!ames!ut-sally!ut-ngp!bigtex!james 306To: vixie!paul 307Status: RO 308 309Yes!!! There are several critical failures in System V cron... 310 3111. Pass all variables in cron's environment into the environment of things 312 cron starts up, or at least into the crontab entries started up (at jobs 313 will inherit the environment of the user). If nothing else it is critically 314 important that the TZ variable be passed on. PATH should be passed on too. 315 Basically, passing environment values allows one to design a standard 316 environment with TZ and PATH and have that run by everything. If anyone 317 tells you this is no big deal, consider what happens when uucico is 318 started by cron in CA to make a long distance phone link... Unless the 319 administrator is really on his/her toes, calls scheduled at 5pm will really 320 go at two in the afternoon, needlessly incurring huge phone bills, all 321 because System V refuses to pass the TZ from its environment down. There 322 are work arounds, but only putting it in cron will really work. This is 323 not a security hole. 324 325<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and 326 PATH through undisturbed. any other requests out there? 327 328 BSD doesn't have this problem -- TZ is passed right on through if 329 you define it in the shell before starting my cron daemon. However, 330 the BSD I'm running this on doesn't need TZ to be defined anyway... 331 The default in the kernel has been just fine so far... But just the 332 same, if/when I port to SysV (I guess I really should), I'll make 333 sure this works right. 334 335 I guess I've been spoiled. HPUX is SysV-based, and I never had a 336 problem with cron and TZ when I used it. >> 337 3382. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry 339 run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates 340 three lines of text, for a total of 432 lines of text I don't want to see. 341 Obviously this should be optional, but it would be nice if there were a 342 way to flag an entry so that it wasn't logged at all unless there was an 343 error. 344 345<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file? 346 I don't see any reason to create log entries, given the mail-the- 347 output behaviour. Opinions, anyone? >> 348 349I will come up with other ideas no doubt, but I can always implement them 350myself. 351 352<< That's what I like about PD software. Please send me the diffs! >> 353 354The other problem you have is making sure you can run standard 355crontabs. I would suggest something like this: if the command part of the 356entry starts with an unescaped -, then flags and options follow immediately 357thereafter. As in: 358 3592,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr 360 361This could mean do not log the uudemon.hr run unless there is a problem of 362some kind. This is probably safe as not many filenames start with "-", and 363those that do are already a problem for people. 364 365<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless 366 many people request it, I won't be needing -q as you've defined it. 367 I could use something like this to avoid sending mail on errors, for 368 the occasional script that you don't want to bullet-proof. 369 370 The compatibility issue is CRITICAL. The 4.3BSD crontab format is 371 a crime against the whole philosophy of Unix(TM), in my opinion. >> 372 373One other minor thing to consider is the ulimit: can different users get 374different ulimits for their crontab entries? 375 376<< Boy I'm ignorant today. What's a ulimit, and what should I do with 377 it in a crontab? Suggestions, enlightenment, etc ?? >> 378 379From qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987 380Date: Thu, 1 Jan 87 10:53:05 pst 381From: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433) 382To: vixie!paul 383Status: RO 384 385How about not hardwiring the default environment that cron builds for its 386children in the cron program itself? Our cron does this and it's the pits 387because we are TZ=PST8PDT not TZ=EST5EDT ! 388 389<< yeachk. I assure you, I will not hardwire the TZ! >> 390From ptsfa!well!dv Fri Jan 9 04:01:50 1987 391Date: Thu, 8 Jan 87 23:50:40 pst 392From: well!dv (David W. Vezie) 393To: ptsfa!vixie!paul 394Status: RO 395 3966, have a special notation called 'H' which would expand to weekends 397 and holidays (you'd have to keep a database somewhere of real 398 holidays), and also 'W' for workdays (neither weekend or holiday). 399 400<< Too much work. There should be a standard way to define and 401 detect holidays under Unix(TM); if there were, I'd use it. As 402 it is, I'll leave this for someone else to add. 403 404 I can see the usefulness; it just doesn't quite seem worth it. >> 405From qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987 406Date: Tue, 13 Jan 87 16:39:38 EST 407From: gatech!akgua!blnt1!jat 408Status: RO 409 4101) Add some way to tell cron to reread the files, say kill -1 <pid> 411 412<< whenever the 'crontab' program is run and updates a crontab file, 413 a file /usr/spool/cron/POKECRON is created; next time the cron 414 daemon wakes up, it sees it, and re-reads the crontab files. 415 416 I thought of handling the signal; even implemented it. Then this 417 clever idea hit me and I ripped it all out and added a single 418 IF-statement to handle the POKECRON file. >> 419 4202) Have some kind of retry time so that if a command fails, cron will try to 421 execute it again after a certain period. This is useful if you have some 422 type of cleanup program that can run at the scheduled time for some reason 423 (such as locked device, unmounted filesystem, etc). 424 425<< Hmmm, sounds useful. I could do this by submitting an 'at' job... 426 I'll think about it. >> 427From ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987 428From: dual!ucbvax!ihnp4!mtuxo!ender 429Date: Sat, 3 Jan 87 14:05:13 PST 430To: ucbvax!dual!ptsfa!vixie!paul 431Status: RO 432 433It would be nice if nonprivileged users can setup personal crontab files 434(~/.cronrc, say) and be able to run personal jobs at regular intervals. 435 436<< this is done, but in the SysV style: the 'crontab' program installs 437 a new crontab file for the executing user (can be overridden by root 438 for setup of uucp and news). the advantage of this is that (1) when 439 a crontab is changed, the daemon can be informed automatically; and 440 (2) the file can be syntax-checked before installation. >> 441From ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987 442Date: Fri, 16 Jan 87 07:44:57 EST 443To: nike!ptsfa!vixie!paul 444Status: RO 445 446The System V cron is nice, but it has a few annoying features. One is that 447its mail files will say that the previous message is the output of "one of your 448cron commands." I wish it would say WHICH cron command. 449 450<< Done. Also which shell, which user (useful when the mail gets 451 forwarded), which home directory, and other useful crud. >> 452 453Another problem is with timezones. It is necessary to specify TZ=PST8PDT (or 454whatever) when you invoke cron (from inittab, or /etc/rc) and it is also 455necessary to add TZ=PST8PDT to each crontab line which might need it. Cron 456should automatically export its idea of the "TZ" to each invoked command, and 457it should be possible to put a line in the crontab file which overrides that 458for every command in the file (e.g., most users are on EST, so cron is run 459with TZ=EST5EDT; but one user is usually on PST and wants all of his cron 460commands to run with TZ=PST8PDT). This might be extended to allow any 461environment variable to be specified once for the whole crontab file (e.g., 462PATH). 463 464<< Well, since I run the user's shell, you could put this into .cshrc. 465 generic environment-variable setting could be useful, though. Since 466 I have to modify the environment anyway, I'll consider this. >> 467 468A log file might be a nice idea, but the System V cron log is too verbose. 469I seem to remember that cron keeps it open, too; so you can't even have 470something go and periodically clean it out. 471 472<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I 473 got all these suggestions. Do people want this file? Tell me! >> 474