summaryrefslogtreecommitdiff
path: root/libexec/cron
diff options
context:
space:
mode:
authormycroft <mycroft@NetBSD.org>1994-01-05 20:52:52 +0000
committermycroft <mycroft@NetBSD.org>1994-01-05 20:52:52 +0000
commit22183f4e79a96aea49a30f0edbb2ad5d02b4b31c (patch)
tree19ab14a1923a62782bbc3d654268dceb56a3e38c /libexec/cron
parent644d4f8787c69abafac395b7a9018e9e9744dcd5 (diff)
Clean up deleted files.
Diffstat (limited to 'libexec/cron')
-rw-r--r--libexec/cron/CHANGES149
-rw-r--r--libexec/cron/CONVERSION85
-rw-r--r--libexec/cron/FEATURES88
-rw-r--r--libexec/cron/MAIL475
-rw-r--r--libexec/cron/MANIFEST30
-rw-r--r--libexec/cron/README72
-rw-r--r--libexec/cron/bitstring.3168
-rw-r--r--libexec/cron/bitstring.h122
-rw-r--r--libexec/cron/putman.sh23
9 files changed, 0 insertions, 1212 deletions
diff --git a/libexec/cron/CHANGES b/libexec/cron/CHANGES
deleted file mode 100644
index 574e68ce555..00000000000
--- 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 <syslog.h>" 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 1347526b04c..00000000000
--- 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 cf91934b867..00000000000
--- 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 f75ae72beab..00000000000
--- 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/<whatever>".
-
-<< 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 <mwm@violet.berkeley.edu>
-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 <pid>
-
-<< 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 a90edb89f7f..00000000000
--- 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 28835bba6fb..00000000000
--- 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 <paul@vix.com> 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 efe9ae3c116..00000000000
--- 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 <bitstring.h>
-
-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 <limits.h>
-#include <bitstring.h>
-
-...
-#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 d054de3c51c..00000000000
--- 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 356ebf1bd30..00000000000
--- 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