On Wednesday 27 September 2006 08:07, Jan Engelhardt wrote:
The 'problem' with cron is that it was designed for periodic tasks, not one-time tasks.
It can be done, though: have your cron job install a separate crontab file, replacing the existing one. At the end of your job (or at the beginning), do: crontab my_new_crontab_file You can keep several different crontab laying around and load them at will. Using 'crontab -e' you can edit the current crontab, and using 'crontab -l' you can dump the current crontab to stdout: crontab -l > my_old_crontab_file To address your earlier post about at: a) 'at' has no built-in support for blocking other tasks. As another user suggested, you'll need to build wrapper scripts and use a lock file. This is not difficult to do in bash. b) the atq output doesn't show the commands you want to run, right - doing so could be a potential security hole, as someone might be able to see, at a glance, what you've got planned. c) The output of the at scripts shows a "lot of junk", but that junk is GOOD junk. It ensures that your at job runs with the environment variables which were set when you set up the job. If this wasn't done, many at jobs would fail mysteriously when vars, like CVS_SSH and HOSTNAME, aren't set. cron has this problem, for example: it's often necessary to source your ~/.profile file at the start of the job if you want to use environment vars which are "system-standard". i don't know of an alternative to 'at', and would recommend (a) for what you're trying to do - lock certain tasks while others are running. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts