crontab update

[Chris Lewis]

In article <1990Mar14.003245.2932 at llustig.uucp> david at llustig.UUCP (David Schachter) writes:
> Someone wrote:
> >>The *only* documented and reliable ways of getting cron to recognize
> >>a new crontab is to use the crontab command.
> 
> Or become root, kill cron, change/add/delete crontab stuff, and re-invoke
> cron.  Violent, but effective.  Not, perhaps, documented, but reliable.  Quite.

Not.  What if something's scheduled to run during the time that cron's dead?
Especially if you have to consult the vi manual... ;-)

Even su root, change/add/delete, kill cron, /etc/cron may miss *something*.
There's still a window of vulnerability, albeit short, but why not do it right
and not have to worry about it?

I had some code using the kill approach.  Worked fine until it missed 
something rather critical....  Got my buns toasted ...

Hell, for automating in scripts, the 

	crontab -l > /tmp/$$ 
	ed - /tmp/$$ <<!
	...
	!
	crontab /tmp/$$

is a lot easier than trying to sed/grep/awk cron's pid from ps output.

The deficiency in this approach is:

	a) There is no documented way I've seen in system V to have root
	   read/alter other people's crontabs.  Which would be extremely handy
	   especially in the case of (b).  AT&T are you listening?  
	   Or have I missed something?
	b) Some vendors make the uucp userid have /usr/lib/uucp/uucico
	   as shell.  How're you supposed to "su uucp" and use crontab?
	   Especially those that don't have uucpadm?....
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list