Linux Crontab Korn Shell Script Primer Tutorial
Linux (or Unix) is a command line environment that supports interactive and non-interactive task management. Often non-interactive tasks are known as batch processes, often intended not to rely on any user intervention, unless there is a problem.
Today, in this tutorial (which builds on Linux Crontab Curl Primer Tutorial ), we see the power of combining a Korn Shell script under the auspices of crontab to run a webpage piece of functionality once a day at a specified time.
For this task today, we imagine what could be good for variety’s sake to do with the landing page and its associated HTML web pages at the www.rjmprogramming.com.au domain. We see the background colour of the header layer div as a good candidate for some dynamic change each day. This id=header_layer HTML element was not specifically covered by any existing CSS, so it could be a very good candidate for our changes.
For such a task, decide whether you want to change HTML or CSS. We decide to change CSS. The Korn Shell script, in this case will need to know a filespec description of the CSS files that would need maintenance … this is determined as … place yourself at document root directory … use `ls *_files/*.css` to get a list of relevant files and use a Korn Shell for loop to loop through these CSS files (to amend). For each file add the relevant CSS … such as
#header_layer {
background-color: white
}
Place this logic into a Korn Shell script and call it dothings_each_day.ksh as one idea. Make sure you set the execute permissions … for example chmod 755 dothings_each_day.ksh
Be logged in as an administrator and perform the Linux command crontab -e and fill in a new record for your new daily crontab job where regarding …
Take a look at some example Linux background processing at this tutorial. In it you will see some crontab work where the parameters are (as explained here … thanks):
MIN = Minute 0-60
HOUR = Hour [24-hour clock] 0-23
MDAY = Day of Month 1-31
MON = Month 1-12 OR jan,feb,mar,apr …
DOW = Day of Week 0-6 OR sun,mon,tue,wed,thu,fri,sat
COMMAND = Command to be run Any valid command-line
… you fill in a specific MIN and HOUR but asterisks for MDAY, MON and DOW, while filling an exact path to your Korn Shell script (for us, dothings_each_day.ksh preceeded by its path) in the COMMAND field.
Voila … you have a once a day change to the landing page and its associated HTML web pages at the www.rjmprogramming.com.au domain. Hope you get, to beget knowledge, out of today’s tutorial. Tomorrow hope you got that begotten knowledge.
Did you know?
The tutorial picture today features the Firefox web browser and a very useful add-on called Firebug which you may want more information about here, which is commonly used to debug client-side Javascript and HTML. As for today’s usage, Firebug is also extremely useful in deconstructing how a web page was created. The other simple wonderful tool for this is the web browser’s equivalent menu command like View->Page Source (or sometimes equivalent of right-click Page Source). Firebug has a sister product called FirePHP which helps debug server-side PHP and Ajax work.
Previous relevant Linux Crontab Curl Primer Tutorial is shown below.
Linux Crontab Curl Primer Tutorial
Linux (or Unix) is a command line environment that supports interactive and non-interactive task management. Often non-interactive tasks are known as batch processes, often intended not to rely on any user intervention, unless there is a problem.
Today, in this tutorial (which builds on Linux Background Primer Tutorial), we see the power of combining Curl under the auspices of crontab to run a webpage piece of functionality once a day at a specified time.
Some CMS systems like Drupal use crontab to perform actions on the database at regular intervals.
For Windows systems you might want to look at Windows Task Schedular for similar functionality.
Linux has several approaches to activating a task, some (not mentioning all the ways one process can fork or launch another process) of them being:
- interactively (from the command line)
- kick off a process from command line, and place in in the background, without supervision, necessarily, via the suffix &
- kick off a process without supervision, necessarily, via crontab
- kick off a process in the background (without supervision, necessarily) via nohup
- kick off a process from command line, and place it in the background, without supervision, necessarily (and optionally change its state via fg and bg)
The previous Linux Background Primer Tutorial is well worth reading below.
Linux Background Primer Tutorial
Linux (or Unix) is a command line environment that supports interactive and non-interactive task management. Often non-interactive tasks are known as batch processes, often intended not to rely on any user intervention, unless there is a problem.
In the pre-GUI days batch processes were very prominent, but they still are today, as far as actually getting things done. It is just that the more glamorous activities pass our notice more, but there are servers out there churning away with batch processes, dreaming of the day when they’ll work out how they can make that cup of coffee for you in the morning. And do we ever offer them even a cup’o’tea … it’s a disgrace, so it is.
Linux has several approaches to activating a task, some (not mentioning all the ways one process can fork or launch another process) of them being:
- interactively (from the command line)
- kick off a process from command line, and place in in the background, without supervision, necessarily, via the suffix &
- kick off a process without supervision, necessarily, via crontab
- kick off a process in the background (without supervision, necessarily) via nohup
- kick off a process from command line, and place it in the background, without supervision, necessarily (and optionally change its state via fg and bg)
The last four above are often best performed on a shell script, whether that be a Bash, Korn, Bourne or Cshell script. There are some good general tips for batch process scripts:
- never assume where you are, rather specify the directory to be in, via “cd”
- never assume that the environment variables will be exactly the same as for an interactive session
- be more thorough to log errors and log activity to files to see, later, what happened
- it is not good to proceed on errors (unless you have set up independent means of checking) because there will be no human to interactively decide that the problem should not stop the job proceeding
- pretty obviously, don’t expect anybody to answer an interactive entry requirement (but you can simulate lots of interactive input via redirected standard input eg. < [filename])
Take a look at some example Linux background processing at this tutorial. In it you will see some crontab work where the parameters are (as explained here … thanks):
MIN = Minute 0-60
HOUR = Hour [24-hour clock] 0-23
MDAY = Day of Month 1-31
MON = Month 1-12 OR jan,feb,mar,apr …
DOW = Day of Week 0-6 OR sun,mon,tue,wed,thu,fri,sat
COMMAND = Command to be run Any valid command-line
The */6 * * * * /Applications/MAMP/htdocs/pdftoimage.sh of our usage runs /Applications/MAMP/htdocs/pdftoimage.sh every six minutes.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
