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