Shell Programming and Scripting

So download and run your own crond as mentioned ....

You do not need to rewrite, in a shell script, code available in C to build and / install in your own directory and run yourself.

Hello,

OK, here's a quick hacked-together version of a script that more-or-less does what crond would do. As Neo has mentioned however, this is not the best idea, as you're kind of needlessly re-inventing something that already exists and which will definitely do a far better job than this shell script. If the customer/client/maintainer/whoever actively doesn't want you running scheduled tasks on the server, then they're not going to be happy about you doing it no matter how you go about doing it. Alternatively if you have a hard requirement to run scheduled tasks and the customer just doesn't want you installing software, then you need to have a conversation with your customer explaining that they need to install crond to enable you to do the work that you've been asked to do, otherwise you can't do it. If the job you need to do has a 100% requirement for scheduled tasks, then whoever provides this system either has to install or let you install crond, or they need to accept that the job can't be done since they won't let you have the tools you need to do it.

Anyway - bearing in mind all the above caveats (and the potential no doubt for bugs and issues that could be lurking with this approach), here's a quickly knocked-together script that would do more or less what you need.

Code:

$ cat cron.tab
Fri,16,13,echo "It's thirteen minutes past four !"
Fri,16,15,echo "It's quarter past four !"
$ cat script3.sh
#!/bin/bash

crontab=/home/unixforum/282472/cron.tab

while true
do
        while read cron
        do
                runday=`echo "$cron" | /usr/bin/awk -F, '{print $1}'`
                runhour=`echo "$cron" | /usr/bin/awk -F, '{print $2}'`
                runminute=`echo "$cron" | /usr/bin/awk -F, '{print $3}'`
                runcommand=`echo "$cron" | /usr/bin/awk -F, '{print $4}'`

                nowday=`/usr/bin/date +%a`
                nowhour=`/usr/bin/date +%H`
                nowminute=`/usr/bin/date +%M`

                if [ "$runday" == "$nowday" ] && [ "$runhour" == "$nowhour" ] && [ "$runminute" == "$nowminute" ]
                then
                        /usr/bin/date
                        $runcommand
                fi
        done < "$crontab"

        /usr/bin/sleep 60
done

$ date
Fri Aug  9 16:11:14 BST 2019
$ ./script3.sh
Fri Aug  9 16:13:16 BST 2019
"It's thirteen minutes past four !"
Fri Aug  9 16:15:16 BST 2019
"It's quarter past four !"
^C
$

thank you very much sir. i will take note of that. from here i will create my own. thx thx..

Probably a daft question, but why can you not use cron? It seems an odd enforcement. If you are writing the code, then you probably have access to do all sorts of nasty stuff anyway. I would not think that a scheduled job is necessarily any more dangerous. The schedules would need to be preserved or shared if you have clustered servers or you migrate to a new server. There may be restrictions that are in place to avoid everybody scheduling loads of things and clogging the machine up and there needs to be some control. Assuming that this job that will do a thing in general rather than for you personally, then maybe a service account would be more suitable (a non-personal account that you/team can sudo to) which could be given access to use cron.

Is there a good reason for the rule? Personally I have not restricted anyone because of one from these:
It's important that jobs run as a person don't become critical to production running, I agree, but that's a cultural thing too. I've had much experience where a savy person has set something up themselves and then they get their PC replaced and it's all lost or credentials to a database change or are restricted and suddenly their entirely unsupported report stops working. It's worse when they leave and nobody knows wheat was done, what it did or anything except "Bob used to do something each month"


Can you say why you are not permitted to use a scheduler? Anything else is either a bad solution calling at repeatedly (probably also restricted) or requires you to have code running all the time all over the place which is exposed to failure and is unlikely to get restarted on boot until you restart it.



Thanks, in advance,
Robin

Be a little careful how you schedule jobs with this concept, as only one job will run at a time and if another job is due and a long running job hasn't finished yet the other job will not be run. Also if the machine is restarted or you script is killed then the jobs will not be run.

Cron is still your preferred option hear, as all these sort of issues, and others we haven't thought of yet, are dealt with out of the box.

My best guest is that it is disguised schoolwork. When people post these types of posts the main reason is that their instructor has told them to "write a script like cron" and then they make up a story about "not having access to cron at work," for example, to get others to help them online.

That's my experience over the past two decades as to why people ask questions with such "constraints" and insist on using a particular solution or approach.