diff --git a/libexec/cron/CHANGES b/libexec/cron/CHANGES deleted file mode 100644 index 574e68ce555d..000000000000 --- a/libexec/cron/CHANGES +++ /dev/null @@ -1,149 +0,0 @@ -Vixie Cron Changes from V2 to V3 -Paul Vixie -29-Dec-1993 - -The crontab command now conforms to POSIX 1003.2. This means that when you -install it, if you have any "crontab" command lines floating around in shell -scripts (such as /etc/rc or /etc/rc.local), you will need to change them. - -I have integrated several changes made by BSDi for their BSD/386 operating -system; these were offerred to me before I started consulting for them, so -it is safe to say that they were intended for publication. Most notably, -the name of the cron daemon has changed from "crond" to "cron". This was -done for compatibility with 4.3BSD. Another change made for the same reason -is the ability to read in an /etc/crontab file which has an extra field in -each entry, between the time fields and the command. This field is a user -name, and it permits the /etc/crontab command to contain commands which are -to be run by any user on the system. /etc/crontab is not "installed" via -the crontab(1) command; it is automatically read at startup time and it will -be reread whenever it changes. - -I also added a "-e" option to crontab(1). Nine people also sent me diffs -to add this option, but I had already implemented it on my own. I actually -released an interrim version (V2.2, I think) for limited testing, and got a -chance to fix a bad security bug in the "-e" option thanks to XXX. - -The daemon used to be extraordinarily sloppy in its use of file descriptors. -A heck of a lot of them were left open in spawned jobs, which caused problems -for the daemon and also caused problems with the spawned jobs if they were -shell scripts since "sh" and "csh" have traditionally used hidden file -descriptors to pass information to subshells, and cron was causing them to -think they were subshells. If you had trouble with "sh" or "csh" scripts in -V2, chances are good that V3 will fix your problems. - -About a dozen people have reminded me that I forgot to initialize "crontab_fd" -in database.c. Keith Cantrell was the first, so he gets the point. - -Steve Simmons reminded me that once an account has been deleted from the system, -"crontab -u USER -d" will not work. My solution is to suggest to all of you that -before you delete a user's account, you first delete that user's crontab file if -any. From cron's point of view, usernames can never be treated as arbitrary -strings. Either they are valid user names, or they are not. I will not make -an exception for the "-d" case, for security reasons that I consider reasonable. -It is trivial for a root user to delete the entry by hand if necessary. - -Dan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of others -also reminded me of this, but Dan gets the point. I didn't fix it there, since the -real bug was that it should have been open in the parent. - -Peter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in misc.c. -Hans Trompert actually told me first, but Peter sent the patch so he gets the point. - -Russell Nelson told me that I'd forgotten to "#include " in misc.c, -which explains why a lot of other people complained that it wasn't using syslog -even when they configured it that way :-). Steve Simmons told me first, though, -so he gets the point. - -An interrim version of the daemon tried to "stat" every file before executing it; -this turned out to be a horribly bad idea since finding the name of a file from -a shell command is a hard job (that's why we have shells, right?) I removed this -bogus code. Dave Burgess gets the point. - -Dennis R. Conley sent a suggestion for MMDF systems, which I've added to the -comments in cron.h. - -Mike Heisler noted that I use comments in the CONVERSION file which are documented -as illegal in the man pages. Thanks, Mike. - -Irving Wolfe sent me some very cheerful changes for a NeXT system, but I consider -the system itself broken and I can't bring myself to #ifdef for something as screwed -up as this system seems to be. Sorry, NeXT users -- pray for POSIX. Irving also -asked for a per-job MAILTO, but the syntactic overkill that would require is more -than I'm willing to add. Remember, on BSD4.2, cron was a 12K daemon. My cron is -about ten times that size already. - -Lots of folks complained that the autogenerated "Date:" header wasn't in ARPA format. -I didn't understand this -- either folks will use Sendmail and not generate a Date: -at all (since Sendmail will do it), or folks will use something other than Sendmail -which won't care about Date: formats. But I've "fixed" it anyway... - -Several people suggested that "*" should be able to take a "/step". One person -suggested that "N/step" ought to mean "N-last/step", but that's stretching things -a bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb -sent in the first and most polite request for this feature. - -As with every release of Cron, BIND, and seemingly everything else I do, one -user stands out with the most critical but also the most useful analysis. -Cron V3's high score belongs to Peter Holzer, who sent in the nicest looking -patch for the "%" interpretation problem and also helped me understand a -tricky bit of badness in the "log_fd" problem. - -agulbra@flode.nvg.unit.no wins the honors for being the first to point out the -nasty security hole in "crontab -r". 'Nuff said. - -Several folks pointed out that log_it() needed to exist even if logging was -disabled. Some day I will create a tool that will compile a subsystem with -every possible combination and permutation of #ifdef options, but meanwhile -thanks to everybody. - -job_runqueue() was using storage after freeing it, since Jordan told me back -in 1983 that C let you do that, and I believed him in 1986 when I wrote all -this junk. Linux was the first to die from this error, and the Linux people -sent me the most amazing, um, collection of patches for this problem. Thanks -for all the fish. - -Jeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's -version of popen/pclose from the ftpd and hacked it to taste. We're safe now, -from this at least. - -Branko Lankester sent me a very timely and helpful fix for a looming security -problem in my "crontab -e" implementation. - --------- - -Vixie Cron Changes from V1 to V2 -Paul Vixie -8-Feb-1988 - -Many changes were made in a rash of activity about six months ago, the exact -list of which is no longer clear in my memory. I know that V1 used a file -called POKECRON in /usr/spool/cron to tell it that it was time to re-read -all the crontab files; V2 uses the modtime the crontab directory as a flag to -check out the crontab files; those whose modtime has changed will be re-read, -and the others left alone. Note that the crontab(1) command will do a utimes -call to make sure the mtime of the dir changes, since the filename/inode will -often remain the same after a replacement and the mtime wouldn't change in -that case. - -8-Feb-88: made it possible to use much larger environment variable strings. - V1 allowed 100 characters; V2 allows 1000. This was needed for PATH - variables on some systems. Thanks to Toerless Eckert for this idea. - E-mail: UUCP: ...pyramid!fauern!faui10!eckert - -16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to - /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, - since the sysv naming for this depends on 'at' using the same - dir, which would be stupid (hint: use /usr/{lib,spool}/at). - -22-Feb-88: made it read the spool directory for crontabs and look each one - up using getpwnam() rather than reading all passwds with getpwent() - and trying to open each crontab. - -9-Dec-88: made it sync to :00 after the minute, makes cron predictable. - added logging to /var/cron/log. - -14-Apr-90: (actually, changes since December 1989) - fixed a number of bugs reported from the net and from John Gilmore. - added syslog per Keith Bostic. security features including not - being willing to run a command owned or writable by other than - the owner of the crontab 9not working well yet) diff --git a/libexec/cron/CONVERSION b/libexec/cron/CONVERSION deleted file mode 100644 index 1347526b04c0..000000000000 --- a/libexec/cron/CONVERSION +++ /dev/null @@ -1,85 +0,0 @@ -$Id: CONVERSION,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $ - -Conversion of BSD 4.[23] crontab files: - -Edit your current crontab (/usr/lib/crontab) into little pieces, with each -users' commands in a different file. This is different on 4.2 and 4.3, -but I'll get to that below. The biggest feature of this cron is that you -can move 'news' and 'uucp' cron commands into files owned and maintainable -by those two users. You also get to rip all the fancy 'su' footwork out -of the cron commands. On 4.3, there's no need for the 'su' stuff since the -user name appears on each command -- but I'd still rather have separate -crontabs with seperate environments and so on. - -Leave the original /usr/lib/crontab! This cron doesn't use it, so you may -as well keep it around for a while in case something goes wakko with this -fancy version. - -Most commands in most crontabs are run by root, have to run by root, and -should continue to be run by root. They still have to be in their own file; -I recommend /etc/crontab.src or /usr/adm/crontab.src. - -'uucp's commands need their own file; how about /usr/lib/uucp/crontab.src? -'news' also, perhaps in /usr/lib/news/crontab.src... - -I say `how about' and `perhaps' because it really doesn't matter to anyone -(except you) where you put the crontab source files. The `crontab' command -COPIES them into a protected directory (CRONDIR/SPOOL_DIR in cron.h), named -after the user whose crontab it is. If you want to examine, replace, or -delete a crontab, the `crontab' command does all of those things. The -various `crontab.src' (my suggested name for them) files are just source -files---they have to be copied to SPOOLDIR using `crontab' before they'll be -executed. - -On 4.2, your crontab might have a few lines like this: - - 5 * * * * su uucp < /usr/lib/uucp/uudemon.hr - 10 4 * * * su uucp < /usr/lib/uucp/uudemon.day - 15 5 * * 0 su uucp < /usr/lib/uucp/uudemon.wk - -...or like this: - - 5 * * * * echo /usr/lib/uucp/uudemon.hr | su uucp - 10 4 * * * echo /usr/lib/uucp/uudemon.day | su uucp - 15 5 * * 0 echo /usr/lib/uucp/uudemon.wk | su uucp - -On 4.3, they'd look a little bit better, but not much: - - 5 * * * * uucp /usr/lib/uucp/uudemon.hr - 10 4 * * * uucp /usr/lib/uucp/uudemon.day - 15 5 * * 0 uucp /usr/lib/uucp/uudemon.wk - -For this cron, you'd create /usr/lib/uucp/crontab.src (or wherever you want -to keep uucp's commands) which would look like this: - - # /usr/lib/uucp/crontab.src - uucp's crontab - # - PATH=/usr/lib/uucp:/bin:/usr/bin - SHELL=/bin/sh - HOME=/usr/lib/uucp - # - 5 * * * * uudemon.hr - 10 4 * * * uudemon.day - 15 5 * * 0 uudemon.wk - -The application to the `news' cron commands (if any) is left for you to -figure out. Likewise if there are any other cruddy-looking 'su' commands in -your crontab commands, you don't need them anymore: just find a good place -to put the `crontab.src' (or whatever you want to call it) file for that -user, put the cron commands into it, and install it using the `crontab' -command (probably with "-u USERNAME", but see the man page). - -If you run a 4.2-derived cron, you could of course just install your current -crontab in toto as root's crontab. It would work exactly the way your -current one does, barring the extra steps in installing or changing it. -There would still be advantages to this cron, mostly that you get mail if -there is any output from your cron commands. - -One note about getting mail from cron: you will probably find, after you -install this version of cron, that your cron commands are generating a lot -of irritating output. The work-around for this is to redirect all EXPECTED -output to a per-execution log file, which you can examine if you want to -see the output from the "last time" a command was executed; if you get any -UNEXPECTED output, it will be mailed to you. This takes a while to get -right, but it's amazingly convenient. Trust me. - diff --git a/libexec/cron/FEATURES b/libexec/cron/FEATURES deleted file mode 100644 index cf91934b867a..000000000000 --- a/libexec/cron/FEATURES +++ /dev/null @@ -1,88 +0,0 @@ -$Id: FEATURES,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $ - -Features of Vixie's cron relative to BSD 4.[23] and SysV crons: - --- Environment variables can be set in each crontab. SHELL, USER, - and HOME are set from the user's passwd entry; all except USER - can be changed in the crontab. PATH is especially useful to - set there. TZ can be set, but cron ignores it other than passing - it on through to the commands it runs. Format is - - variable=value - - Blanks surrounding the '=' will be eaten; other blanks in value are - okay. Leading or trailing blanks can be preserved by quoting, single - or double quotes are okay, just so they match. - - PATH=.:/bin:/usr/bin - SHELL=/bin/sh - FOOBAR = this is a long blanky example - - Above, FOOBAR would get `this is a long blanky example' as its value. - - SHELL and HOME will be examined when it's time to run a command; if - you don't change them, they default to your /etc/passwd entry. - - *DANGER*, WILL ROBINSON! This means that all 'uucp' logins should set - SHELL=/bin/sh or cron will try to use /usr/lib/uucp/uucico as the - shell. This won't work. - - MAILTO, if set to the login name of a user on your system, will be the - person that cron mails the output of commands in that crontab. This is - useful if you decide on BINMAIL when configuring cron.h, since binmail - doesn't know anything about aliasing. - - Setting SHELL=/bin/sh will in general speed up your commands since it - is a much smaller shell than the one you probably use normally (csh - or ksh) and has enough features to work non-interactively. - --- Weekdays can be specified by name. Case is not significant, but only - the first three letters should be specified. - --- Months can likewise be specified by name. Three letters only. - --- Ranges and lists can be mixed. Standard crons won't allow '1,3-5'. - --- Ranges can specify 'step' values. '10-16/2' is like '10,12,14,16'. - --- Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree - about this. - --- Each user gets their own crontab file. This is a win over BSD 4.2, - where only root has one, and over BSD 4.3, where they made the crontab - format incompatible and although the commands can be run by non-root - uid's, root is still the only one who can edit the crontab file. This - feature mimics the SysV cron. - --- The 'crontab' command is loosely compatible with SysV, but has more - options which just generally make more sense. Running crontab with - no arguments will print a cute little summary of the command syntax. - --- Comments and blank lines are allowed in the crontab file. Comments - must be on a line by themselves; leading whitespace is ignored, and - a '#' introduces the comment. - --- (big win) If the `crontab' command changes anything in any crontab, it - tells the 'cron' daemon, who reloads all the tables before running the - next iteration. In some crons, you have to kill and restart the - daemon whenever you change a crontab. In other crons, the crontab - file is reread and reparsed every minute even if it didn't change. - --- In order to support the automatic reload, the crontab files are not - readable or writable except by 'crontab' or 'cron'. This is not a - problem, since 'crontab' will let you do pretty much whatever you - want to your own crontab, or if you are root, to anybody's crontab. - --- If any output is generated by a command (on stdout OR stderr), it will - be mailed to the owner of the crontab that contained the command (or - MAILTO, see discussion of environment variables, above). The headers - of the mail message will include the command that was run, and a - complete list of the environment that was passed to it, which will - contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL. - --- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the - first and fifteenth AND every Sunday; '* * * * Sun' will run *only* - on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this - is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up - this behaviour; it's how cron has always worked but the documentation - hasn't been very clear. diff --git a/libexec/cron/MAIL b/libexec/cron/MAIL deleted file mode 100644 index f75ae72beab5..000000000000 --- a/libexec/cron/MAIL +++ /dev/null @@ -1,475 +0,0 @@ -[ this is really old mail that came to me in response to my 1986 posting - to usenet asking for feature suggestions before releasing the first - version of cron. it is presented here for its entertainment value. - --vix ] - -$Id: MAIL,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $ - -From ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986 -Date: Wed, 31 Dec 86 08:59:31 pst -From: lll-crg!ames!acornrc!bob (Bob Weissman) -To: ptsfa!vixie!paul -Status: RO - -Sure, here's a suggestion: I'd like to be able to run a program, say, -every two hours. Current cron requires me to write -0,2,4,6,8,10,12,14,16,18,20,22 in the hours field. How about a notation -to handle this more elegantly? - -<< Okay, I've allowed 0-22/2 as a means of handling this. - The time specification for my cron is as follows: - specification = range {"," range} - range = (start "-" finish ["/" step]) | single-unit - This allows "1,3,5-7", which the current cron doesn't (it won't - do a range inside a list), and handles your specific need. >> - -From drw@mit-eddie Wed Dec 31 18:25:27 1986 -Date: Wed, 31 Dec 86 14:28:19 est -From: drw@mit-eddie (Dale Worley) -To: mit-eddie!vixie!paul -Status: RO - -We have a lot of lines in our crontab of the form - - 00 12 * * * su user < /usr/users/user/script.file - -This barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if -user's shell is csh. This, I am told, is because csh requires that -the environment be set up in certain ways, which cron doesn't do. -(Actually, I believe, it is because /etc/rc, which runs cron, doesn't -set up the environment enough for csh to run, and cron just inherits -the situation.) Anyway, the point is that if you find out what csh -really needs in its environment, you might want to set up cron to -provide some reasonable defaults (if it isn't supplied by cron's -parent). Also, could you tell me what csh needs, if you find out, so -we can hack our /etc/rc? - -<< well, the environment IS a problem. processes that cron forks - will inherit the environment of the person who ran the cron - daemon... I plan to edit out such useless things as TERMCAP, - TERM, and the like; supply correct values for HOME, USER, CWD, - and whatever else comes to mind. I'll make sure csh works... >> -From ptsfa!ames!seismo!dgis!generous Thu Jan 1 07:33:17 1987 -Date: Thu Jan 1 10:29:20 1987 -From: ames!seismo!dgis!generous (Curtis Generous) -To: nike!ptsfa!vixie!paul -Status: RO - -Paul: - -One of the limitations of the present versions of cron is the lack -of the capability of specifying a way to execute a command every -n units of time. - -Here is a good example: - -# Present method to start up uucico -02,12,22,32,42,52 * * * * exec /usr/lib/uucp/uucico -r1 - -# New method ?? (the ':' here is just one possibility for syntax) -02:10 * * * * exec /usr/lib/uucp/uucico -r1 - -This method would prove very helpful for those programs that get started -every few minutes, making the entry long and not easily readable. The first -number would specify the base time, and the second number the repetition -interval. - -<< Good idea, but bob@acornrc beat you to it. I used '/' instead of - ':'. This is my personal preference, and seems intuitive when you - think of the divide operator in C... Does anyone have a preference? >> - -From ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan 1 17:04:24 1987 -From: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green) -To: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul -Date: Thu Jan 1 19:22:47 1987 -Status: RO - -Well, this isn't a compatible extension, but I have in times past wondered -about a facility to let you start a process at intervals of, say, 17 minutes, -instead of particular minutes out of each hour. - -<< This was a popular request! >> - -From seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan 4 13:04:01 1987 -Date: Fri, 2 Jan 87 09:23:53 cst -From: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann) -To: ptsfa!vixie!paul -Status: RO - -I'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't -figured it out ) but a comment feature would SURE BE NICE!. -There are times when I want to comment out an entry -for a period of time; it might also make it a lot more legible. - -<< My cron allows blank lines and standard #-type comments. I know - that one BSD4.2 cron I've used had it. I don't know about SysV. >> - -From ptsfa!hoptoad!hugh Mon Jan 5 10:26:46 1987 -Date: Mon, 5 Jan 87 01:22:17 PST -From: hoptoad!hugh (Hugh Daniel) -To: ptsfa!vixie!paul -Status: RO - - Hi, I do have a BIG one that I would like. I want to log ALL output -from command lines into a file for each line. Thus I might have a chance -of finding out why my crontab entry did not work. - This would seem to work best if done by cron, as it is now I have a google -of shell scripts laying about just to put the error output where I can see -it. - -<< My cron (and the SysV cron) will send mail to the owner of the - particular crontab file if a command generates any output on stdout - or stderr. This can be irritating, but if you write a script such - that any output means a problem occurred, you can avoid most logfile - needs, and not generate mail except in unforeseen circumstances. >> - -From ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan 5 13:08:46 1987 -From: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen -Date: Fri, 2 Jan 87 14:25:29 EST -To: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul -Status: RO - -Here are some suggestions: -1. Run it through the C preprocessor via "/lib/". - -<< hmmm. this seems of limited utility, and if you really wanted - to do it that way, you could do it yourself (since users can - write to their own crontab files). I'll add '-' (read stdin) - to the crontab installer program to facilitate this. >> - -2. Allow specifying every Nth day of week, i.e., every second Wednesday. - I did this to calendar by separating the day of week (Wed=4, which one - to start on and N with slashes). I took modulo the day of year as a - starting point so that someone with a desk calendar documenting such - things can easily determine the offset (second number). I did this - while at SGI; alas I don't have a copy of the code. - -<< I can see how this could be useful, but I'm not sure how I'd - implement it. Cron currently doesn't keep track of the last time - a given command was run; whether the current Wednesday is the first - or second since the command was last run would be pretty hard to - figure out. I'd have to keep a database of commands and their - execution around, and purge it when the crontab was overwritten. - This is too much work for me, but if someone adds it, let me know. >> - -From ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan 6 05:50:17 1987 -From: ames!seismo!cbmvax!devon!paul -To: cbmvax!seismo!nike!ptsfa!vixie!paul -Date: Mon Jan 5 09:29:57 1987 -Status: RO - -One problem that has always plagued me with cron is the assumed ORing. -I'd like to see some type of ANDing implemented. I guess I can best -describe this by example. Say I have the following line in my crontab -file: - -* * 4-31 * 1-6 /usr/bin/command - -What this does is run 'command' on the 4th thru 31st days of the -month, AND on Monday thru Saturday; which probably means running it -every day of the month (unless Sunday falls on days 1-3). This -happens because cron runs the command if the day-of-month OR the -day-of-week is true. - -What I'd like to happen with the above line is to run the command ONLY -on Monday thru Saturday any time after the 3rd of the month, e.g. if -the day-of-month AND the day-of-week are true. - -My proposal to you is to implement some special chars for the first -five fields. Examples: - -* * !1-3 * 1-6 /usr/bin/command - -(run command Mon-Sat, but NOT [!] on the first 3 days of the month) - -* * &4-31 * &1-6 /usr/bin/command - -(run command if day-of-month AND day-of-week are true) - -Get the picture? This would be compatable with existing versions of -cron (which wouldn't currently be using any special characters, so -that old crontabs would be handled correctly). - -<< This message made me aware of the actual boolean expression involved - in a crontab entry. I'd assumed that it was - (minute && hour && DoM && month && DoW) - But it's really - (minute && hour && month && (DoM || DoW)) - - I can see some value in changing this, but with a fixed order of - fields, operators get to be kindof unary, which && and || really - aren't. If someone has an idea on a syntax that allows useful - variations to the standard (&& && && (||)) default, please suggest. >> - -From bobkat!pedz Tue Jan 6 20:02:10 1987 -From: pedz@bobkat.UUCP (Pedz Thing) -Date: 2 Jan 87 17:34:44 GMT -Status: RO - -Log files! It would be nice to be able to specify a log for cron -itself and also a log for each program's stdout and stderr to go to. -The latter can of course be done with > and 2> but it would be nice if -there could be a single line with some sort of pattern like -`> /usr/spool/log/%' and the command would be substituted for the %. -Another thing which would be nice is to be able to specify which shell -to call to give the command to. - -<< Log files are done with mail. The '%' idea could be useful if - a different character were used (% is special to cron, see man - page); a different directory would have to be chosen, since each - user has their own crontab file; and something intelligent would - have to be done in the file naming, since the first word of the - command might be ambiguous (with other commands). In short, it's - too much work. Sorry. >> - -From guy%gorodish@sun Tue Jan 6 20:03:13 1987 -From: guy%gorodish@sun (Guy Harris) -Message-ID: <10944@sun.uucp> -Date: 5 Jan 87 12:09:09 GMT -References: <429@vixie.UUCP> <359@bobkat.UUCP> -Sender: news@sun.uucp -Status: RO - -> Another thing which would be nice is to be able to specify which shell -> to call to give the command to. - -Well, the obvious choice would be the user's shell, but this wouldn't work -for accounts like "uucico". - -<< I use the owning user's shell, and to handle "uucico" I check a - list of "acceptable shells" (currently compiled in, does anybody - mind?), substituting a default (compiled in) shell if the user's - shell isn't on the list. - - BTW, "compiled in" means that it's in a .h file, easily changed - during installation, but requiring recompilation to modify. You - don't have to go digging through the code to find it... >> - -From qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987 -To: hplabs!qantel!vixie!paul (Paul Vixie Esq) -Date: 04 Jan 87 00:42:35 PST (Sun) -From: Mike Meyer -Status: RO - -<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>> - -Oh, yeah - here are the extensions on my cron: - -1) Sunday is both day 0 and day 7, so it complies with both SysV and -BSD cron. - -<< Good idea. I did it too, thanks for informing me. >> - -2) At is integrated into the cron. Instead of atrun to scan the -/usr/spool/at directory, at files are put into the /usr/lib/cron -directory along with users cron files, and cron fabricates a line from -a crontab file to run them. This is considered a major win by all who -use it. - -<< I don't use 'at', and my cron doesn't do anything with it. To run - 'at', I use 'atrun' the same way the current BSD cron does. My - crontab files are in /usr/spool/cron/crontabs, in the SysV - tradition -- not in /usr/lib/cron. This is a configuration - parameter, of course. >> - -There are two known restrictions: - -1) I don't support any of the SysV security hooks. I don't have a use -for them, and RMS didn't like the idea at all :-). - -<< This means cron.allow and cron.deny. I plan to support them, as - they've been quite helpful at various HPUX sites I've administered. >> - -2) Cron expects to be able to create files with names longer than 14 -characters, which makes it hard to run on SysV. At least one person -was working on a port, but I don't know how it's going. That might -make for a good reason for releasing yours, right there. - -<< If someone has SysV (with the 14-character limit), they probably - won't want my cron, since it doesn't add much to the standard - version (which they may have support for). My cron is not currently - portable to non-BSD systems, since it relies on interval timers (I - needed to sleep for intervals more granular than seconds alone would - allow). The port would be trivial, and I will do it if a lot of - people ask for it... >> - -Oh, yeah - I'm going to see about getting this cron integrated into -the next 4BSD release. - -<< How does one go about this? I have a few nifty gadgets I'd like - to contribute, this cron being one of them... >> - -<<[more FSF/GNU discussion deleted]>> - -From qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987 -Posted-Date: Fri, 2 Jan 87 19:26:16 est -Date: Fri, 2 Jan 87 19:26:16 est -From: hplabs!ames!ut-sally!ut-ngp!bigtex!james -To: vixie!paul -Status: RO - -Yes!!! There are several critical failures in System V cron... - -1. Pass all variables in cron's environment into the environment of things - cron starts up, or at least into the crontab entries started up (at jobs - will inherit the environment of the user). If nothing else it is critically - important that the TZ variable be passed on. PATH should be passed on too. - Basically, passing environment values allows one to design a standard - environment with TZ and PATH and have that run by everything. If anyone - tells you this is no big deal, consider what happens when uucico is - started by cron in CA to make a long distance phone link... Unless the - administrator is really on his/her toes, calls scheduled at 5pm will really - go at two in the afternoon, needlessly incurring huge phone bills, all - because System V refuses to pass the TZ from its environment down. There - are work arounds, but only putting it in cron will really work. This is - not a security hole. - -<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and - PATH through undisturbed. any other requests out there? - - BSD doesn't have this problem -- TZ is passed right on through if - you define it in the shell before starting my cron daemon. However, - the BSD I'm running this on doesn't need TZ to be defined anyway... - The default in the kernel has been just fine so far... But just the - same, if/when I port to SysV (I guess I really should), I'll make - sure this works right. - - I guess I've been spoiled. HPUX is SysV-based, and I never had a - problem with cron and TZ when I used it. >> - -2. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry - run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates - three lines of text, for a total of 432 lines of text I don't want to see. - Obviously this should be optional, but it would be nice if there were a - way to flag an entry so that it wasn't logged at all unless there was an - error. - -<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file? - I don't see any reason to create log entries, given the mail-the- - output behaviour. Opinions, anyone? >> - -I will come up with other ideas no doubt, but I can always implement them -myself. - -<< That's what I like about PD software. Please send me the diffs! >> - -The other problem you have is making sure you can run standard -crontabs. I would suggest something like this: if the command part of the -entry starts with an unescaped -, then flags and options follow immediately -thereafter. As in: - -2,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr - -This could mean do not log the uudemon.hr run unless there is a problem of -some kind. This is probably safe as not many filenames start with "-", and -those that do are already a problem for people. - -<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless - many people request it, I won't be needing -q as you've defined it. - I could use something like this to avoid sending mail on errors, for - the occasional script that you don't want to bullet-proof. - - The compatibility issue is CRITICAL. The 4.3BSD crontab format is - a crime against the whole philosophy of Unix(TM), in my opinion. >> - -One other minor thing to consider is the ulimit: can different users get -different ulimits for their crontab entries? - -<< Boy I'm ignorant today. What's a ulimit, and what should I do with - it in a crontab? Suggestions, enlightenment, etc ?? >> - -From qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987 -Date: Thu, 1 Jan 87 10:53:05 pst -From: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433) -To: vixie!paul -Status: RO - -How about not hardwiring the default environment that cron builds for its -children in the cron program itself? Our cron does this and it's the pits -because we are TZ=PST8PDT not TZ=EST5EDT ! - -<< yeachk. I assure you, I will not hardwire the TZ! >> -From ptsfa!well!dv Fri Jan 9 04:01:50 1987 -Date: Thu, 8 Jan 87 23:50:40 pst -From: well!dv (David W. Vezie) -To: ptsfa!vixie!paul -Status: RO - -6, have a special notation called 'H' which would expand to weekends - and holidays (you'd have to keep a database somewhere of real - holidays), and also 'W' for workdays (neither weekend or holiday). - -<< Too much work. There should be a standard way to define and - detect holidays under Unix(TM); if there were, I'd use it. As - it is, I'll leave this for someone else to add. - - I can see the usefulness; it just doesn't quite seem worth it. >> -From qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987 -Date: Tue, 13 Jan 87 16:39:38 EST -From: gatech!akgua!blnt1!jat -Status: RO - -1) Add some way to tell cron to reread the files, say kill -1 - -<< whenever the 'crontab' program is run and updates a crontab file, - a file /usr/spool/cron/POKECRON is created; next time the cron - daemon wakes up, it sees it, and re-reads the crontab files. - - I thought of handling the signal; even implemented it. Then this - clever idea hit me and I ripped it all out and added a single - IF-statement to handle the POKECRON file. >> - -2) Have some kind of retry time so that if a command fails, cron will try to - execute it again after a certain period. This is useful if you have some - type of cleanup program that can run at the scheduled time for some reason - (such as locked device, unmounted filesystem, etc). - -<< Hmmm, sounds useful. I could do this by submitting an 'at' job... - I'll think about it. >> -From ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987 -From: dual!ucbvax!ihnp4!mtuxo!ender -Date: Sat, 3 Jan 87 14:05:13 PST -To: ucbvax!dual!ptsfa!vixie!paul -Status: RO - -It would be nice if nonprivileged users can setup personal crontab files -(~/.cronrc, say) and be able to run personal jobs at regular intervals. - -<< this is done, but in the SysV style: the 'crontab' program installs - a new crontab file for the executing user (can be overridden by root - for setup of uucp and news). the advantage of this is that (1) when - a crontab is changed, the daemon can be informed automatically; and - (2) the file can be syntax-checked before installation. >> -From ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987 -Date: Fri, 16 Jan 87 07:44:57 EST -To: nike!ptsfa!vixie!paul -Status: RO - -The System V cron is nice, but it has a few annoying features. One is that -its mail files will say that the previous message is the output of "one of your -cron commands." I wish it would say WHICH cron commmand. - -<< Done. Also which shell, which user (useful when the mail gets - forwarded), which home directory, and other useful crud. >> - -Another problem is with timezones. It is necessary to specify TZ=PST8PDT (or -whatever) when you invoke cron (from inittab, or /etc/rc) and it is also -necessary to add TZ=PST8PDT to each crontab line which might need it. Cron -should automatically export its idea of the "TZ" to each invoked command, and -it should be possible to put a line in the crontab file which overrides that -for every command in the file (e.g., most users are on EST, so cron is run -with TZ=EST5EDT; but one user is usually on PST and wants all of his cron -commands to run with TZ=PST8PDT). This might be extended to allow any -environment variable to be specified once for the whole crontab file (e.g., -PATH). - -<< Well, since I run the user's shell, you could put this into .cshrc. - generic environment-variable setting could be useful, though. Since - I have to modify the environment anyway, I'll consider this. >> - -A log file might be a nice idea, but the System V cron log is too verbose. -I seem to remember that cron keeps it open, too; so you can't even have -something go and periodically clean it out. - -<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I - got all these suggestions. Do people want this file? Tell me! >> diff --git a/libexec/cron/MANIFEST b/libexec/cron/MANIFEST deleted file mode 100644 index a90edb89f7f9..000000000000 --- a/libexec/cron/MANIFEST +++ /dev/null @@ -1,30 +0,0 @@ - File Name Archive # Description ------------------------------------------------------------ - CHANGES 1 - CONVERSION 1 - FEATURES 1 - INSTALL 1 - MAIL 2 - MANIFEST 1 This shipping list - Makefile 1 - README 1 - THANKS 1 - bitstring.3 1 - bitstring.h 1 - config.h 1 - cron.8 1 - cron.c 1 - cron.h 1 - crontab.1 1 - crontab.5 1 - crontab.c 2 - database.c 1 - do_command.c 2 - entry.c 2 - env.c 1 - externs.h 1 - job.c 1 - misc.c 2 - pathnames.h 1 - popen.c 1 - user.c 1 diff --git a/libexec/cron/README b/libexec/cron/README deleted file mode 100644 index 28835bba6fb3..000000000000 --- a/libexec/cron/README +++ /dev/null @@ -1,72 +0,0 @@ -#/* Copyright 1988,1990,1993 by Paul Vixie -# * All rights reserved -# * -# * Distribute freely, except: don't remove my name from the source or -# * documentation (don't take credit for my work), mark your changes (don't -# * get me blamed for your possible bugs), don't alter or remove this -# * notice. May be sold if buildable source is provided to buyer. No -# * warrantee of any kind, express or implied, is included with this -# * software; use at your own risk, responsibility for damages (if any) to -# * anyone resulting from the use of this software rests entirely with the -# * user. -# * -# * Send bug reports, bug fixes, enhancements, requests, flames, etc., and -# * I'll try to keep a version up to date. I can be reached as follows: -# * Paul Vixie uunet!decwrl!vixie!paul -# */ - -Vixie Cron V3.0 -December 27, 1993 -[V2.2 was some time in 1992] -[V2.1 was May 29, 1991] -[V2.0 was July 5, 1990] -[V2.0-beta was December 9, 1988] -[V1.0 was May 6, 1987] -Paul Vixie - -This is a version of 'cron' that is known to run on BSD 4.[23] systems. It -is functionally based on the SysV cron, which means that each user can have -their own crontab file (all crontab files are stored in a read-protected -directory, usually /var/cron/tabs). No direct support is provided for -'at'; you can continue to run 'atrun' from the crontab as you have been -doing. If you don't have atrun (i.e., System V) you are in trouble. - -A messages is logged each time a command is executed; also, the files -"allow" and "deny" in /var/cron can be used to control access to the -"crontab" command (which installs crontabs). It hasn't been tested on -SysV, although some effort has gone into making the port an easy one. - -This is more or less the copyright that USENET contributed software usually -has. Since ATT couldn't use this version if they had to freely distribute -source, and since I'd love to see them use it, I'll offer some rediculously -low license fee just to have them take it. In the unlikely event that they -do this, I will continue to support and distribute the pseudo-PD version, so -please, don't flame me for wanting my work to see a wider distribution. - -To use this: Sorry, folks, there is no cutesy 'Configure' script. You'll -have to go edit a couple of files... So, here's the checklist: - - Read all the FEATURES, INSTALL, and CONVERSION files - Edit config.h - Edit Makefile - (both of these files have instructions inside; note that - some things in config.h are definable in Makefile and are - therefore surrounded by #ifndef...#endif) - 'make' - 'su' and 'make install' - (you may have to install the man pages by hand) - kill your existing cron process - (actually you can run your existing cron if you want, but why?) - build new crontabs using /usr/lib/{crontab,crontab.local} - (either put them all in "root"'s crontab, or divide it up - and rip out all the 'su' commands, collapse the lengthy - lists into ranges with steps -- basically, this step is - as much work as you want to make it) - start up the new cron - (must be done as root) - watch it. test it with 'crontab -r' and watch the daemon track your - changes. - if you like it, change your /etc/{rc,rc.local} to use it instead of - the old one. - -$Id: README,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $ diff --git a/libexec/cron/bitstring.3 b/libexec/cron/bitstring.3 deleted file mode 100644 index efe9ae3c116e..000000000000 --- a/libexec/cron/bitstring.3 +++ /dev/null @@ -1,168 +0,0 @@ -.\" Copyright (c) 1989 The Regents of the University of California. -.\" All rights reserved. -.\" -.\" This code is derived from software contributed to Berkeley by -.\" Paul Vixie. -.\" -.\" Redistribution and use in source and binary forms are permitted -.\" provided that the above copyright notice and this paragraph are -.\" duplicated in all such forms and that any documentation, -.\" advertising materials, and other materials related to such -.\" distribution and use acknowledge that the software was developed -.\" by the University of California, Berkeley. The name of the -.\" University may not be used to endorse or promote products derived -.\" from this software without specific prior written permission. -.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR -.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED -.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. -.\" -.\" @(#)bitstring.3 5.1 (Berkeley) 12/13/89 -.\" -.TH BITSTRING 3 "December 13, 1989" -.UC 4 -.SH NAME -bit_alloc, bit_clear, bit_decl, bit_ffs, bit_nclear, bit_nset, -bit_set, bitstr_size, bit_test \- bit-string manipulation macros -.SH SYNOPSIS -.ft B -.nf -#include - -name = bit_alloc(nbits) -bitstr_t *name; -int nbits; - -bit_decl(name, nbits) -bitstr_t name; -int nbits; - -bit_clear(name, bit) -bitstr_t name; -int bit; - -bit_ffc(name, nbits, value) -bitstr_t name; -int nbits, *value; - -bit_ffs(name, nbits, value) -bitstr_t name; -int nbits, *value; - -bit_nclear(name, start, stop) -bitstr_t name; -int start, stop; - -bit_nset(name, start, stop) -bitstr_t name; -int start, stop; - -bit_set(name, bit) -bitstr_t name; -int bit; - -bitstr_size(nbits) -int nbits; - -bit_test(name, bit) -bitstr_t name; -int bit; -.fi -.ft R -.SH DESCRIPTION -These macros operate on strings of bits. -.PP -.I Bit_alloc -returns a pointer of type -.I bitstr_t\ * -to sufficient space to store -.I nbits -bits, or NULL if no space is available. -.PP -.I Bit_decl -is a macro for allocating sufficient space to store -.I nbits -bits on the stack. -.PP -.I Bitstr_size -returns the number of elements of type -.I bitstr_t -necessary to store -.I nbits -bits. -This is useful for copying bit strings. -.PP -.I Bit_clear -and -.I bit_set -clear or set the zero-based numbered bit -.IR bit , -in the bit string -.IR name . -.PP -.I Bit_nset -and -.I bit_nclear -set or clear the zero-based numbered bits from -.I start -to -.I stop -in the bit string -.IR name . -.PP -.I Bit_test -evaluates to zero if the zero-based numbered bit -.I bit -of bit string -.I name -is set, and non-zero otherwise. -.PP -.I Bit_ffs -sets -.I *value -to the zero-based number of the first bit set in the array of -.I nbits -bits referenced by -.IR name . -If no bits are set, -.I *value -is set to -1. -.PP -.I Bit_ffc -sets -.I *value -to the zero-based number of the first bit not set in the array of -.I nbits -bits referenced by -.IR name . -If all bits are set, -.I value -is set to -1. -.SH EXAMPLE -.nf -.in +5 -#include -#include - -... -#define LPR_BUSY_BIT 0 -#define LPR_FORMAT_BIT 1 -#define LPR_DOWNLOAD_BIT 2 -... -#define LPR_AVAILABLE_BIT 9 -#define LPR_MAX_BITS 10 - -make_lpr_available() -{ - bitstr_t bit_decl(bitlist, LPR_MAX_BITS); - ... - bit_nclear(bitlist, 0, LPR_MAX_BITS - 1); - ... - if (!bit_test(bitlist, LPR_BUSY_BIT)) { - bit_clear(bitlist, LPR_FORMAT_BIT); - bit_clear(bitlist, LPR_DOWNLOAD_BIT); - bit_set(bitlist, LPR_AVAILABLE_BIT); - } -} -.fi -.SH "SEE ALSO" -malloc(3) diff --git a/libexec/cron/bitstring.h b/libexec/cron/bitstring.h deleted file mode 100644 index d054de3c51c1..000000000000 --- a/libexec/cron/bitstring.h +++ /dev/null @@ -1,122 +0,0 @@ -/* - * Copyright (c) 1989 The Regents of the University of California. - * All rights reserved. - * - * This code is derived from software contributed to Berkeley by - * Paul Vixie. - * - * Redistribution and use in source and binary forms are permitted - * provided that the above copyright notice and this paragraph are - * duplicated in all such forms and that any documentation, - * advertising materials, and other materials related to such - * distribution and use acknowledge that the software was developed - * by the University of California, Berkeley. The name of the - * University may not be used to endorse or promote products derived - * from this software without specific prior written permission. - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. - * - * @(#)bitstring.h 5.2 (Berkeley) 4/4/90 - */ - -typedef unsigned char bitstr_t; - -/* internal macros */ - /* byte of the bitstring bit is in */ -#define _bit_byte(bit) \ - ((bit) >> 3) - - /* mask for the bit within its byte */ -#define _bit_mask(bit) \ - (1 << ((bit)&0x7)) - -/* external macros */ - /* bytes in a bitstring of nbits bits */ -#define bitstr_size(nbits) \ - ((((nbits) - 1) >> 3) + 1) - - /* allocate a bitstring */ -#define bit_alloc(nbits) \ - (bitstr_t *)malloc(1, \ - (unsigned int)bitstr_size(nbits) * sizeof(bitstr_t)) - - /* allocate a bitstring on the stack */ -#define bit_decl(name, nbits) \ - (name)[bitstr_size(nbits)] - - /* is bit N of bitstring name set? */ -#define bit_test(name, bit) \ - ((name)[_bit_byte(bit)] & _bit_mask(bit)) - - /* set bit N of bitstring name */ -#define bit_set(name, bit) \ - (name)[_bit_byte(bit)] |= _bit_mask(bit) - - /* clear bit N of bitstring name */ -#define bit_clear(name, bit) \ - (name)[_bit_byte(bit)] &= ~_bit_mask(bit) - - /* clear bits start ... stop in bitstring */ -#define bit_nclear(name, start, stop) { \ - register bitstr_t *_name = name; \ - register int _start = start, _stop = stop; \ - register int _startbyte = _bit_byte(_start); \ - register int _stopbyte = _bit_byte(_stop); \ - if (_startbyte == _stopbyte) { \ - _name[_startbyte] &= ((0xff >> (8 - (_start&0x7))) | \ - (0xff << ((_stop&0x7) + 1))); \ - } else { \ - _name[_startbyte] &= 0xff >> (8 - (_start&0x7)); \ - while (++_startbyte < _stopbyte) \ - _name[_startbyte] = 0; \ - _name[_stopbyte] &= 0xff << ((_stop&0x7) + 1); \ - } \ -} - - /* set bits start ... stop in bitstring */ -#define bit_nset(name, start, stop) { \ - register bitstr_t *_name = name; \ - register int _start = start, _stop = stop; \ - register int _startbyte = _bit_byte(_start); \ - register int _stopbyte = _bit_byte(_stop); \ - if (_startbyte == _stopbyte) { \ - _name[_startbyte] |= ((0xff << (_start&0x7)) & \ - (0xff >> (7 - (_stop&0x7)))); \ - } else { \ - _name[_startbyte] |= 0xff << ((_start)&0x7); \ - while (++_startbyte < _stopbyte) \ - _name[_startbyte] = 0xff; \ - _name[_stopbyte] |= 0xff >> (7 - (_stop&0x7)); \ - } \ -} - - /* find first bit clear in name */ -#define bit_ffc(name, nbits, value) { \ - register bitstr_t *_name = name; \ - register int _byte, _nbits = nbits; \ - register int _stopbyte = _bit_byte(_nbits), _value = -1; \ - for (_byte = 0; _byte <= _stopbyte; ++_byte) \ - if (_name[_byte] != 0xff) { \ - _value = _byte << 3; \ - for (_stopbyte = _name[_byte]; (_stopbyte&0x1); \ - ++_value, _stopbyte >>= 1); \ - break; \ - } \ - *(value) = _value; \ -} - - /* find first bit set in name */ -#define bit_ffs(name, nbits, value) { \ - register bitstr_t *_name = name; \ - register int _byte, _nbits = nbits; \ - register int _stopbyte = _bit_byte(_nbits), _value = -1; \ - for (_byte = 0; _byte <= _stopbyte; ++_byte) \ - if (_name[_byte]) { \ - _value = _byte << 3; \ - for (_stopbyte = _name[_byte]; !(_stopbyte&0x1); \ - ++_value, _stopbyte >>= 1); \ - break; \ - } \ - *(value) = _value; \ -} diff --git a/libexec/cron/putman.sh b/libexec/cron/putman.sh deleted file mode 100644 index 356ebf1bd305..000000000000 --- a/libexec/cron/putman.sh +++ /dev/null @@ -1,23 +0,0 @@ -#!/bin/sh - -# putman.sh - install a man page according to local custom -# vixie 27dec93 [original] -# -# $Id: putman.sh,v 1.1.1.1 1994/01/05 20:40:16 jtc Exp $ - -PAGE=$1 -DIR=$2 - -SECT=`expr $PAGE : '[a-z]*.\([0-9]\)'` - -[ -d $DIR/man$SECT ] && { - set -x - cp $PAGE $DIR/man$SECT/$PAGE - set +x -} || { - set -x - nroff -man $PAGE >$DIR/cat$SECT/`basename $PAGE .$SECT`.0 - set +x -} - -exit 0