Re: Infinte perl script

You don't need root access to run thing in cron (I only know linux but I assume cron would be constant). Just type:
% crontab -ujoseph -e
This edits the personal cron for user joseph instead of the main system one. For more information talk to the man (ie % man crontab)

Another choice is the at command. You could end every invocation of your program with:

open AT,"/usr/bin/at now + 20 minutes" or die; 
print AT "/usr/bin/perl $0\nEOF";
close AT;
[download]

At least thats my untested guesses on how to do it.

Comment on Re: Infinte perl script - Part 2 Select or Download Code

Replies are listed 'Best First'.
Re (tilly) 2: Infinte perl script - Part 2 by tilly (Archbishop) on Jan 06, 2001 at 19:02 UTC
This advice is only somewhat true. Whether or not a particular machine allows cron to be run from user accounts depends on how that machine is configured. Look up the crontab command on your machine. Generally there can be files (on mine /etc/cron.allow and /etc/cron.deny) which control who can use cron. In general it is not a good idea to have critical production jobs running from user accounts. Have production users for that... Also note that crons are something which I do not recommend editing directly. They are usually important, and are too easy to mess up. Instead have a file under version control (which I tend to name "crontab", YMMV) which you edit, and then do `crontab crontab` to install. That way if you do something wrong, you know you can get back to your old crontab very easily. Many people use named backups of key files instead of real version control. It kind of works, but real version control is much, much better.	[reply]

Replies are listed 'Best First'.

Re (tilly) 2: Infinte perl script - Part 2
by tilly (Archbishop) on Jan 06, 2001 at 19:02 UTC

Whether or not a particular machine allows cron to be run from user accounts depends on how that machine is configured. Look up the crontab command on your machine. Generally there can be files (on mine /etc/cron.allow and /etc/cron.deny) which control who can use cron. In general it is not a good idea to have critical production jobs running from user accounts. Have production users for that...

Also note that crons are something which I do not recommend editing directly. They are usually important, and are too easy to mess up. Instead have a file under version control (which I tend to name "crontab", YMMV) which you edit, and then do crontab crontab to install. That way if you do something wrong, you know you can get back to your old crontab very easily.

Many people use named backups of key files instead of real version control. It kind of works, but real version control is much, much better.

[reply]