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