12311Sjkh[ this is really old mail that came to me in response to my 1986 posting 22311Sjkh to usenet asking for feature suggestions before releasing the first 32311Sjkh version of cron. it is presented here for its entertainment value. 42311Sjkh --vix ] 52311Sjkh 650479Speter$FreeBSD: releng/11.0/usr.sbin/cron/doc/MAIL 228990 2011-12-30 10:58:14Z uqs $ 72311Sjkh 82311SjkhFrom ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986 92311SjkhDate: Wed, 31 Dec 86 08:59:31 pst 102311SjkhFrom: lll-crg!ames!acornrc!bob (Bob Weissman) 112311SjkhTo: ptsfa!vixie!paul 122311SjkhStatus: RO 132311Sjkh 142311SjkhSure, here's a suggestion: I'd like to be able to run a program, say, 152311Sjkhevery two hours. Current cron requires me to write 162311Sjkh0,2,4,6,8,10,12,14,16,18,20,22 in the hours field. How about a notation 172311Sjkhto handle this more elegantly? 182311Sjkh 192311Sjkh<< Okay, I've allowed 0-22/2 as a means of handling this. 202311Sjkh The time specification for my cron is as follows: 212311Sjkh specification = range {"," range} 222311Sjkh range = (start "-" finish ["/" step]) | single-unit 232311Sjkh This allows "1,3,5-7", which the current cron doesn't (it won't 242311Sjkh do a range inside a list), and handles your specific need. >> 252311Sjkh 262311SjkhFrom drw@mit-eddie Wed Dec 31 18:25:27 1986 272311SjkhDate: Wed, 31 Dec 86 14:28:19 est 282311SjkhFrom: drw@mit-eddie (Dale Worley) 292311SjkhTo: mit-eddie!vixie!paul 302311SjkhStatus: RO 312311Sjkh 322311SjkhWe have a lot of lines in our crontab of the form 332311Sjkh 342311Sjkh 00 12 * * * su user < /usr/users/user/script.file 352311Sjkh 362311SjkhThis barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if 372311Sjkhuser's shell is csh. This, I am told, is because csh requires that 382311Sjkhthe environment be set up in certain ways, which cron doesn't do. 392311Sjkh(Actually, I believe, it is because /etc/rc, which runs cron, doesn't 402311Sjkhset up the environment enough for csh to run, and cron just inherits 412311Sjkhthe situation.) Anyway, the point is that if you find out what csh 422311Sjkhreally needs in its environment, you might want to set up cron to 432311Sjkhprovide some reasonable defaults (if it isn't supplied by cron's 442311Sjkhparent). Also, could you tell me what csh needs, if you find out, so 452311Sjkhwe can hack our /etc/rc? 462311Sjkh 472311Sjkh<< well, the environment IS a problem. processes that cron forks 482311Sjkh will inherit the environment of the person who ran the cron 492311Sjkh daemon... I plan to edit out such useless things as TERMCAP, 502311Sjkh TERM, and the like; supply correct values for HOME, USER, CWD, 512311Sjkh and whatever else comes to mind. I'll make sure csh works... >> 522311SjkhFrom ptsfa!ames!seismo!dgis!generous Thu Jan 1 07:33:17 1987 532311SjkhDate: Thu Jan 1 10:29:20 1987 542311SjkhFrom: ames!seismo!dgis!generous (Curtis Generous) 552311SjkhTo: nike!ptsfa!vixie!paul 562311SjkhStatus: RO 572311Sjkh 582311SjkhPaul: 592311Sjkh 602311SjkhOne of the limitations of the present versions of cron is the lack 612311Sjkhof the capability of specifying a way to execute a command every 622311Sjkhn units of time. 632311Sjkh 642311SjkhHere is a good example: 652311Sjkh 662311Sjkh# Present method to start up uucico 672311Sjkh02,12,22,32,42,52 * * * * exec /usr/lib/uucp/uucico -r1 682311Sjkh 692311Sjkh# New method ?? (the ':' here is just one possibility for syntax) 702311Sjkh02:10 * * * * exec /usr/lib/uucp/uucico -r1 712311Sjkh 722311SjkhThis method would prove very helpful for those programs that get started 732311Sjkhevery few minutes, making the entry long and not easily readable. The first 742311Sjkhnumber would specify the base time, and the second number the repetition 752311Sjkhinterval. 762311Sjkh 772311Sjkh<< Good idea, but bob@acornrc beat you to it. I used '/' instead of 782311Sjkh ':'. This is my personal preference, and seems intuitive when you 792311Sjkh think of the divide operator in C... Does anyone have a preference? >> 802311Sjkh 812311SjkhFrom ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan 1 17:04:24 1987 822311SjkhFrom: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green) 832311SjkhTo: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul 842311SjkhDate: Thu Jan 1 19:22:47 1987 852311SjkhStatus: RO 862311Sjkh 872311SjkhWell, this isn't a compatible extension, but I have in times past wondered 882311Sjkhabout a facility to let you start a process at intervals of, say, 17 minutes, 892311Sjkhinstead of particular minutes out of each hour. 902311Sjkh 912311Sjkh<< This was a popular request! >> 922311Sjkh 932311SjkhFrom seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan 4 13:04:01 1987 942311SjkhDate: Fri, 2 Jan 87 09:23:53 cst 952311SjkhFrom: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann) 962311SjkhTo: ptsfa!vixie!paul 972311SjkhStatus: RO 982311Sjkh 992311SjkhI'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't 1002311Sjkhfigured it out ) but a comment feature would SURE BE NICE!. 1012311SjkhThere are times when I want to comment out an entry 1022311Sjkhfor a period of time; it might also make it a lot more legible. 1032311Sjkh 1042311Sjkh<< My cron allows blank lines and standard #-type comments. I know 1052311Sjkh that one BSD4.2 cron I've used had it. I don't know about SysV. >> 1062311Sjkh 1072311SjkhFrom ptsfa!hoptoad!hugh Mon Jan 5 10:26:46 1987 1082311SjkhDate: Mon, 5 Jan 87 01:22:17 PST 1092311SjkhFrom: hoptoad!hugh (Hugh Daniel) 1102311SjkhTo: ptsfa!vixie!paul 1112311SjkhStatus: RO 1122311Sjkh 1132311Sjkh Hi, I do have a BIG one that I would like. I want to log ALL output 1142311Sjkhfrom command lines into a file for each line. Thus I might have a chance 1152311Sjkhof finding out why my crontab entry did not work. 1162311Sjkh This would seem to work best if done by cron, as it is now I have a google 1172311Sjkhof shell scripts laying about just to put the error output where I can see 1182311Sjkhit. 1192311Sjkh 1202311Sjkh<< My cron (and the SysV cron) will send mail to the owner of the 1212311Sjkh particular crontab file if a command generates any output on stdout 1222311Sjkh or stderr. This can be irritating, but if you write a script such 1232311Sjkh that any output means a problem occurred, you can avoid most logfile 1242311Sjkh needs, and not generate mail except in unforeseen circumstances. >> 1252311Sjkh 1262311SjkhFrom ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan 5 13:08:46 1987 1272311SjkhFrom: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen 1282311SjkhDate: Fri, 2 Jan 87 14:25:29 EST 1292311SjkhTo: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul 1302311SjkhStatus: RO 1312311Sjkh 1322311SjkhHere are some suggestions: 1332311Sjkh1. Run it through the C preprocessor via "/lib/<whatever>". 1342311Sjkh 1352311Sjkh<< hmmm. this seems of limited utility, and if you really wanted 1362311Sjkh to do it that way, you could do it yourself (since users can 1372311Sjkh write to their own crontab files). I'll add '-' (read stdin) 1382311Sjkh to the crontab installer program to facilitate this. >> 1392311Sjkh 1402311Sjkh2. Allow specifying every Nth day of week, i.e., every second Wednesday. 1412311Sjkh I did this to calendar by separating the day of week (Wed=4, which one 1422311Sjkh to start on and N with slashes). I took modulo the day of year as a 1432311Sjkh starting point so that someone with a desk calendar documenting such 1442311Sjkh things can easily determine the offset (second number). I did this 1452311Sjkh while at SGI; alas I don't have a copy of the code. 1462311Sjkh 1472311Sjkh<< I can see how this could be useful, but I'm not sure how I'd 1482311Sjkh implement it. Cron currently doesn't keep track of the last time 1492311Sjkh a given command was run; whether the current Wednesday is the first 1502311Sjkh or second since the command was last run would be pretty hard to 1512311Sjkh figure out. I'd have to keep a database of commands and their 1522311Sjkh execution around, and purge it when the crontab was overwritten. 1532311Sjkh This is too much work for me, but if someone adds it, let me know. >> 1542311Sjkh 1552311SjkhFrom ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan 6 05:50:17 1987 1562311SjkhFrom: ames!seismo!cbmvax!devon!paul 1572311SjkhTo: cbmvax!seismo!nike!ptsfa!vixie!paul 1582311SjkhDate: Mon Jan 5 09:29:57 1987 1592311SjkhStatus: RO 1602311Sjkh 1612311SjkhOne problem that has always plagued me with cron is the assumed ORing. 1622311SjkhI'd like to see some type of ANDing implemented. I guess I can best 1632311Sjkhdescribe this by example. Say I have the following line in my crontab 1642311Sjkhfile: 1652311Sjkh 1662311Sjkh* * 4-31 * 1-6 /usr/bin/command 1672311Sjkh 1682311SjkhWhat this does is run 'command' on the 4th thru 31st days of the 1692311Sjkhmonth, AND on Monday thru Saturday; which probably means running it 1702311Sjkhevery day of the month (unless Sunday falls on days 1-3). This 1712311Sjkhhappens because cron runs the command if the day-of-month OR the 1722311Sjkhday-of-week is true. 1732311Sjkh 1742311SjkhWhat I'd like to happen with the above line is to run the command ONLY 1752311Sjkhon Monday thru Saturday any time after the 3rd of the month, e.g. if 1762311Sjkhthe day-of-month AND the day-of-week are true. 1772311Sjkh 1782311SjkhMy proposal to you is to implement some special chars for the first 1792311Sjkhfive fields. Examples: 1802311Sjkh 1812311Sjkh* * !1-3 * 1-6 /usr/bin/command 1822311Sjkh 1832311Sjkh(run command Mon-Sat, but NOT [!] on the first 3 days of the month) 1842311Sjkh 1852311Sjkh* * &4-31 * &1-6 /usr/bin/command 1862311Sjkh 1872311Sjkh(run command if day-of-month AND day-of-week are true) 1882311Sjkh 189228990SuqsGet the picture? This would be compatible with existing versions of 1902311Sjkhcron (which wouldn't currently be using any special characters, so 1912311Sjkhthat old crontabs would be handled correctly). 1922311Sjkh 1932311Sjkh<< This message made me aware of the actual boolean expression involved 1942311Sjkh in a crontab entry. I'd assumed that it was 1952311Sjkh (minute && hour && DoM && month && DoW) 1962311Sjkh But it's really 1972311Sjkh (minute && hour && month && (DoM || DoW)) 1982311Sjkh 1992311Sjkh I can see some value in changing this, but with a fixed order of 2002311Sjkh fields, operators get to be kindof unary, which && and || really 2012311Sjkh aren't. If someone has an idea on a syntax that allows useful 2022311Sjkh variations to the standard (&& && && (||)) default, please suggest. >> 2032311Sjkh 2042311SjkhFrom bobkat!pedz Tue Jan 6 20:02:10 1987 2052311SjkhFrom: pedz@bobkat.UUCP (Pedz Thing) 2062311SjkhDate: 2 Jan 87 17:34:44 GMT 2072311SjkhStatus: RO 2082311Sjkh 2092311SjkhLog files! It would be nice to be able to specify a log for cron 2102311Sjkhitself and also a log for each program's stdout and stderr to go to. 2112311SjkhThe latter can of course be done with > and 2> but it would be nice if 2122311Sjkhthere could be a single line with some sort of pattern like 2132311Sjkh`> /usr/spool/log/%' and the command would be substituted for the %. 2142311SjkhAnother thing which would be nice is to be able to specify which shell 2152311Sjkhto call to give the command to. 2162311Sjkh 2172311Sjkh<< Log files are done with mail. The '%' idea could be useful if 2182311Sjkh a different character were used (% is special to cron, see man 2192311Sjkh page); a different directory would have to be chosen, since each 2202311Sjkh user has their own crontab file; and something intelligent would 2212311Sjkh have to be done in the file naming, since the first word of the 2222311Sjkh command might be ambiguous (with other commands). In short, it's 2232311Sjkh too much work. Sorry. >> 2242311Sjkh 2252311SjkhFrom guy%gorodish@sun Tue Jan 6 20:03:13 1987 2262311SjkhFrom: guy%gorodish@sun (Guy Harris) 2272311SjkhMessage-ID: <10944@sun.uucp> 2282311SjkhDate: 5 Jan 87 12:09:09 GMT 2292311SjkhReferences: <429@vixie.UUCP> <359@bobkat.UUCP> 2302311SjkhSender: news@sun.uucp 2312311SjkhStatus: RO 2322311Sjkh 2332311Sjkh> Another thing which would be nice is to be able to specify which shell 2342311Sjkh> to call to give the command to. 2352311Sjkh 2362311SjkhWell, the obvious choice would be the user's shell, but this wouldn't work 2372311Sjkhfor accounts like "uucico". 2382311Sjkh 2392311Sjkh<< I use the owning user's shell, and to handle "uucico" I check a 2402311Sjkh list of "acceptable shells" (currently compiled in, does anybody 2412311Sjkh mind?), substituting a default (compiled in) shell if the user's 2422311Sjkh shell isn't on the list. 2432311Sjkh 2442311Sjkh BTW, "compiled in" means that it's in a .h file, easily changed 2452311Sjkh during installation, but requiring recompilation to modify. You 2462311Sjkh don't have to go digging through the code to find it... >> 2472311Sjkh 2482311SjkhFrom qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987 2492311SjkhTo: hplabs!qantel!vixie!paul (Paul Vixie Esq) 2502311SjkhDate: 04 Jan 87 00:42:35 PST (Sun) 2512311SjkhFrom: Mike Meyer <mwm@violet.berkeley.edu> 2522311SjkhStatus: RO 2532311Sjkh 2542311Sjkh<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>> 2552311Sjkh 2562311SjkhOh, yeah - here are the extensions on my cron: 2572311Sjkh 2582311Sjkh1) Sunday is both day 0 and day 7, so it complies with both SysV and 2592311SjkhBSD cron. 2602311Sjkh 2612311Sjkh<< Good idea. I did it too, thanks for informing me. >> 2622311Sjkh 2632311Sjkh2) At is integrated into the cron. Instead of atrun to scan the 2642311Sjkh/usr/spool/at directory, at files are put into the /usr/lib/cron 2652311Sjkhdirectory along with users cron files, and cron fabricates a line from 2662311Sjkha crontab file to run them. This is considered a major win by all who 2672311Sjkhuse it. 2682311Sjkh 2692311Sjkh<< I don't use 'at', and my cron doesn't do anything with it. To run 2702311Sjkh 'at', I use 'atrun' the same way the current BSD cron does. My 2712311Sjkh crontab files are in /usr/spool/cron/crontabs, in the SysV 2722311Sjkh tradition -- not in /usr/lib/cron. This is a configuration 2732311Sjkh parameter, of course. >> 2742311Sjkh 2752311SjkhThere are two known restrictions: 2762311Sjkh 2772311Sjkh1) I don't support any of the SysV security hooks. I don't have a use 2782311Sjkhfor them, and RMS didn't like the idea at all :-). 2792311Sjkh 2802311Sjkh<< This means cron.allow and cron.deny. I plan to support them, as 2812311Sjkh they've been quite helpful at various HPUX sites I've administered. >> 2822311Sjkh 2832311Sjkh2) Cron expects to be able to create files with names longer than 14 2842311Sjkhcharacters, which makes it hard to run on SysV. At least one person 2852311Sjkhwas working on a port, but I don't know how it's going. That might 2862311Sjkhmake for a good reason for releasing yours, right there. 2872311Sjkh 2882311Sjkh<< If someone has SysV (with the 14-character limit), they probably 2892311Sjkh won't want my cron, since it doesn't add much to the standard 2902311Sjkh version (which they may have support for). My cron is not currently 2912311Sjkh portable to non-BSD systems, since it relies on interval timers (I 2922311Sjkh needed to sleep for intervals more granular than seconds alone would 2932311Sjkh allow). The port would be trivial, and I will do it if a lot of 2942311Sjkh people ask for it... >> 2952311Sjkh 2962311SjkhOh, yeah - I'm going to see about getting this cron integrated into 2972311Sjkhthe next 4BSD release. 2982311Sjkh 2992311Sjkh<< How does one go about this? I have a few nifty gadgets I'd like 3002311Sjkh to contribute, this cron being one of them... >> 3012311Sjkh 3022311Sjkh<<[more FSF/GNU discussion deleted]>> 3032311Sjkh 3042311SjkhFrom qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987 3052311SjkhPosted-Date: Fri, 2 Jan 87 19:26:16 est 3062311SjkhDate: Fri, 2 Jan 87 19:26:16 est 3072311SjkhFrom: hplabs!ames!ut-sally!ut-ngp!bigtex!james 3082311SjkhTo: vixie!paul 3092311SjkhStatus: RO 3102311Sjkh 3112311SjkhYes!!! There are several critical failures in System V cron... 3122311Sjkh 3132311Sjkh1. Pass all variables in cron's environment into the environment of things 3142311Sjkh cron starts up, or at least into the crontab entries started up (at jobs 3152311Sjkh will inherit the environment of the user). If nothing else it is critically 3162311Sjkh important that the TZ variable be passed on. PATH should be passed on too. 3172311Sjkh Basically, passing environment values allows one to design a standard 3182311Sjkh environment with TZ and PATH and have that run by everything. If anyone 3192311Sjkh tells you this is no big deal, consider what happens when uucico is 3202311Sjkh started by cron in CA to make a long distance phone link... Unless the 3212311Sjkh administrator is really on his/her toes, calls scheduled at 5pm will really 3222311Sjkh go at two in the afternoon, needlessly incurring huge phone bills, all 3232311Sjkh because System V refuses to pass the TZ from its environment down. There 3242311Sjkh are work arounds, but only putting it in cron will really work. This is 3252311Sjkh not a security hole. 3262311Sjkh 3272311Sjkh<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and 3282311Sjkh PATH through undisturbed. any other requests out there? 3292311Sjkh 3302311Sjkh BSD doesn't have this problem -- TZ is passed right on through if 3312311Sjkh you define it in the shell before starting my cron daemon. However, 3322311Sjkh the BSD I'm running this on doesn't need TZ to be defined anyway... 3332311Sjkh The default in the kernel has been just fine so far... But just the 3342311Sjkh same, if/when I port to SysV (I guess I really should), I'll make 3352311Sjkh sure this works right. 3362311Sjkh 3372311Sjkh I guess I've been spoiled. HPUX is SysV-based, and I never had a 3382311Sjkh problem with cron and TZ when I used it. >> 3392311Sjkh 3402311Sjkh2. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry 3412311Sjkh run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates 3422311Sjkh three lines of text, for a total of 432 lines of text I don't want to see. 3432311Sjkh Obviously this should be optional, but it would be nice if there were a 3442311Sjkh way to flag an entry so that it wasn't logged at all unless there was an 3452311Sjkh error. 3462311Sjkh 3472311Sjkh<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file? 3482311Sjkh I don't see any reason to create log entries, given the mail-the- 3492311Sjkh output behaviour. Opinions, anyone? >> 3502311Sjkh 3512311SjkhI will come up with other ideas no doubt, but I can always implement them 3522311Sjkhmyself. 3532311Sjkh 3542311Sjkh<< That's what I like about PD software. Please send me the diffs! >> 3552311Sjkh 3562311SjkhThe other problem you have is making sure you can run standard 3572311Sjkhcrontabs. I would suggest something like this: if the command part of the 3582311Sjkhentry starts with an unescaped -, then flags and options follow immediately 3592311Sjkhthereafter. As in: 3602311Sjkh 3612311Sjkh2,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr 3622311Sjkh 3632311SjkhThis could mean do not log the uudemon.hr run unless there is a problem of 3642311Sjkhsome kind. This is probably safe as not many filenames start with "-", and 3652311Sjkhthose that do are already a problem for people. 3662311Sjkh 3672311Sjkh<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless 3682311Sjkh many people request it, I won't be needing -q as you've defined it. 3692311Sjkh I could use something like this to avoid sending mail on errors, for 3702311Sjkh the occasional script that you don't want to bullet-proof. 3712311Sjkh 3722311Sjkh The compatibility issue is CRITICAL. The 4.3BSD crontab format is 3732311Sjkh a crime against the whole philosophy of Unix(TM), in my opinion. >> 3742311Sjkh 3752311SjkhOne other minor thing to consider is the ulimit: can different users get 3762311Sjkhdifferent ulimits for their crontab entries? 3772311Sjkh 3782311Sjkh<< Boy I'm ignorant today. What's a ulimit, and what should I do with 3792311Sjkh it in a crontab? Suggestions, enlightenment, etc ?? >> 3802311Sjkh 3812311SjkhFrom qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987 3822311SjkhDate: Thu, 1 Jan 87 10:53:05 pst 3832311SjkhFrom: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433) 3842311SjkhTo: vixie!paul 3852311SjkhStatus: RO 3862311Sjkh 3872311SjkhHow about not hardwiring the default environment that cron builds for its 3882311Sjkhchildren in the cron program itself? Our cron does this and it's the pits 3892311Sjkhbecause we are TZ=PST8PDT not TZ=EST5EDT ! 3902311Sjkh 3912311Sjkh<< yeachk. I assure you, I will not hardwire the TZ! >> 3922311SjkhFrom ptsfa!well!dv Fri Jan 9 04:01:50 1987 3932311SjkhDate: Thu, 8 Jan 87 23:50:40 pst 3942311SjkhFrom: well!dv (David W. Vezie) 3952311SjkhTo: ptsfa!vixie!paul 3962311SjkhStatus: RO 3972311Sjkh 3982311Sjkh6, have a special notation called 'H' which would expand to weekends 3992311Sjkh and holidays (you'd have to keep a database somewhere of real 4002311Sjkh holidays), and also 'W' for workdays (neither weekend or holiday). 4012311Sjkh 4022311Sjkh<< Too much work. There should be a standard way to define and 4032311Sjkh detect holidays under Unix(TM); if there were, I'd use it. As 4042311Sjkh it is, I'll leave this for someone else to add. 4052311Sjkh 4062311Sjkh I can see the usefulness; it just doesn't quite seem worth it. >> 4072311SjkhFrom qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987 4082311SjkhDate: Tue, 13 Jan 87 16:39:38 EST 4092311SjkhFrom: gatech!akgua!blnt1!jat 4102311SjkhStatus: RO 4112311Sjkh 4122311Sjkh1) Add some way to tell cron to reread the files, say kill -1 <pid> 4132311Sjkh 4142311Sjkh<< whenever the 'crontab' program is run and updates a crontab file, 4152311Sjkh a file /usr/spool/cron/POKECRON is created; next time the cron 4162311Sjkh daemon wakes up, it sees it, and re-reads the crontab files. 4172311Sjkh 4182311Sjkh I thought of handling the signal; even implemented it. Then this 4192311Sjkh clever idea hit me and I ripped it all out and added a single 4202311Sjkh IF-statement to handle the POKECRON file. >> 4212311Sjkh 4222311Sjkh2) Have some kind of retry time so that if a command fails, cron will try to 4232311Sjkh execute it again after a certain period. This is useful if you have some 4242311Sjkh type of cleanup program that can run at the scheduled time for some reason 4252311Sjkh (such as locked device, unmounted filesystem, etc). 4262311Sjkh 4272311Sjkh<< Hmmm, sounds useful. I could do this by submitting an 'at' job... 4282311Sjkh I'll think about it. >> 4292311SjkhFrom ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987 4302311SjkhFrom: dual!ucbvax!ihnp4!mtuxo!ender 4312311SjkhDate: Sat, 3 Jan 87 14:05:13 PST 4322311SjkhTo: ucbvax!dual!ptsfa!vixie!paul 4332311SjkhStatus: RO 4342311Sjkh 4352311SjkhIt would be nice if nonprivileged users can setup personal crontab files 4362311Sjkh(~/.cronrc, say) and be able to run personal jobs at regular intervals. 4372311Sjkh 4382311Sjkh<< this is done, but in the SysV style: the 'crontab' program installs 4392311Sjkh a new crontab file for the executing user (can be overridden by root 4402311Sjkh for setup of uucp and news). the advantage of this is that (1) when 4412311Sjkh a crontab is changed, the daemon can be informed automatically; and 4422311Sjkh (2) the file can be syntax-checked before installation. >> 4432311SjkhFrom ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987 4442311SjkhDate: Fri, 16 Jan 87 07:44:57 EST 4452311SjkhTo: nike!ptsfa!vixie!paul 4462311SjkhStatus: RO 4472311Sjkh 4482311SjkhThe System V cron is nice, but it has a few annoying features. One is that 4492311Sjkhits mail files will say that the previous message is the output of "one of your 4502311Sjkhcron commands." I wish it would say WHICH cron commmand. 4512311Sjkh 4522311Sjkh<< Done. Also which shell, which user (useful when the mail gets 4532311Sjkh forwarded), which home directory, and other useful crud. >> 4542311Sjkh 4552311SjkhAnother problem is with timezones. It is necessary to specify TZ=PST8PDT (or 4562311Sjkhwhatever) when you invoke cron (from inittab, or /etc/rc) and it is also 4572311Sjkhnecessary to add TZ=PST8PDT to each crontab line which might need it. Cron 4582311Sjkhshould automatically export its idea of the "TZ" to each invoked command, and 4592311Sjkhit should be possible to put a line in the crontab file which overrides that 4602311Sjkhfor every command in the file (e.g., most users are on EST, so cron is run 4612311Sjkhwith TZ=EST5EDT; but one user is usually on PST and wants all of his cron 4622311Sjkhcommands to run with TZ=PST8PDT). This might be extended to allow any 4632311Sjkhenvironment variable to be specified once for the whole crontab file (e.g., 4642311SjkhPATH). 4652311Sjkh 4662311Sjkh<< Well, since I run the user's shell, you could put this into .cshrc. 4672311Sjkh generic environment-variable setting could be useful, though. Since 4682311Sjkh I have to modify the environment anyway, I'll consider this. >> 4692311Sjkh 4702311SjkhA log file might be a nice idea, but the System V cron log is too verbose. 4712311SjkhI seem to remember that cron keeps it open, too; so you can't even have 4722311Sjkhsomething go and periodically clean it out. 4732311Sjkh 4742311Sjkh<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I 4752311Sjkh got all these suggestions. Do people want this file? Tell me! >> 476