a quick search shows Schedule::Cron on CPAN.

You can also use a

while (1){
 ...
 sleep 1;
}
[download]

loop and use Algorithm::Cron to parse your file: see also my cron-explain.pl -- cron next appointments.

Probably also a queue manager like Minion can be used.

L*

There is Schedule::Cron, which you can use to run something like your own cron daemon on the machine.

If you have a shell account, you should be able to run crontab -e to edit your user crontab.

Just for reference, here is a low level version to execute one thing at a specific time every day (untested, from memory):

...
my $targettimetext = "13:14:15";

# Turn target time into seconds
my @tttparts = split/\:/, $targettimetext;
my $targettime = ($tttparts[0] * 3600) + ($tttparts[1] * 60) + $tttpar
+ts[2];
...

while(1) {
    # Turn the current time into seconds
    my ($sec,$min, $hour, $mday,$mon, $year, $wday,$yday, $isdst) = lo
+caltime time;
    my $nowtime = ($hour * 3600) + ($minute * 60) + $sec;
    
    # Not yet time to do things? Sleep until it is
    if($nowtime < $targettime) {
        sleep($targettime - $nowtime);
    }

    # YOUR STUFF HERE
    
    # Recalculate the current time after doing stuff
    ($sec,$min, $hour, $mday,$mon, $year, $wday,$yday, $isdst) = local
+time time;
    $nowtime = ($hour * 3600) + ($minute * 60) + $sec;
    
    # Sleep for the rest of the day
    sleep(86400 - $nowtime);
}
[download]

Edit: Please be aware, the simplistic approach above doesn't account for all the time calculation weirdness like daylight savings time changes, leap seconds and skipped days. For that, i refer you to this excellent Tom Scott video.

Excellent, indeed! Especially the part from 8:47 to 9:12

True. But on the other hand, that's the same thing people said about data logging, and then went ahead and used Log4J.

Not to mention that "using code other people wrote to solve complicated problems" means quite a few popular image formats (and a lot of other stuff) uses 32 bit timestamps. Meaning i'll probably just make it to retirement before that particular puppy has a major accident on the IT carpet.

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Have you tried running cron as normal(unpriviledged) user? You do not necessarily be root to do so.

Granted there's the whole "easier to ask forgiveness than permission" saw, but consider that your admins may have reasons you (specifically, or users in general) don't have access to cron and by attempting to circumvent that you're possibly setting yourself up for whatever ire and/or retribution that draws (and the related saying there, "Do not meddle in the affairs of sysadmins for they are subtle and quick to anger").

@Corion and @Disciplus,

Thank you!! Do these utilities run independent of crontab or they are wrappers around it? I did quickly browse through the documentation but couldn't be sure hence the question.

> I did quickly browse through the documentation but couldn't be sure hence the question...

the reading of documentation is left happily to you :) but..

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

In order to run a task triggered by a timestamp, there must be some daemon running in the background of the server to start the task. The standard Unix daemons for this are crond and atd. Typically, both give ordinary users the ability to add things to the schedule. (the crontab command and the at command) If this has been disabled by the sysadmin, your remaining options are to run a daemon of your own detached from the terminal, or to schedule something on a different server that uses ssh with a authorized key to log in and run the task.

The perl modules mentioned above let you write a script which could either be a daemon on the server, or a daemon or foreground process somewhere else that calls ssh to the server. You could also take these approaches without using perl by running your own copy of crond.

The recommendation to ask the sysadmin why they disallowed access to Cron and whether they are ok with users running daemons on the server still applies.

@Disciplus. Thank you good sir!!