[ Prev ][ Table of Contents ][ Front Page ][ Talkback ][ FAQ ][ Next ]

"Linux Gazette...making Linux just a little more fun!"

The Weekend Mechanic

By Thomas Adam

Welcome to the new Linux Weekend Mechanic!

Table of Contents

What exactly is the Weekend Mechanic?

Welcome to this months new feature....The Weekend Mechanic. Actually, for those of you who have been avid readers since LG's initial release, you'll realise that this column used to be written by John M Fisk in 1996-1998 and so it is not that new. However, I thought it would be nice to re-introduce this as a regular feature.

The Weekend Mechanic will draw together my experiences of Linux and the problems that I have had to solve either at home or at school each month. So, The Weekend Mechanic will concentrate on the following:

So, with that in mind, lets begin this months fixing and tinkering session......

Customising the Shell Environment

I have noticed that more and more people when using Linux tend solely to rely on the GUI, hoping in vein that they do not have to type in any commands in fear of deleting their work, making a fatal mistake, etc. Although the only real threat of this happening is if you are logged in as "root", I find that people are still wary!! However, there will come a time regardless when typing in commands will be a necessity and it is important that your shell environment is customised so that you can complete your tasks with ease. This article will show you how to customise the login shell so that features such as Aliases, editors, shells, etc can work in the way that you want them to.

Firstly, we should make sure that you have an appropriate editor installed. There are many console editors to choose from, such as: emacs, joe, jed, pico, vi. Once you have found an editor that you like (I happen to use both Pico and Jed) then you can tell the shell to use. Some programs such as Cron (as we shall see later on..) rely on the shell having an editor set up so that you can edit the crontab.

There are two files that we shall be concentrating on. They are located in your home directory as: .bashrc and .bash_profile. In my .bashrc file, I find that it begins with the following:

# User specific aliases and functions

alias ls='ls -o --color=auto'
alias cad='cat /var/squidGuard/db/blacklist/adverts'
alias cc='cd /mnt/cdrom/Mandrake/RPMS'
alias mail='mail -v'
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias d='ls'
alias s='cd ..'
alias p='cd -'

Aliases are useful, especially if you find yourself typing out a command that has a deep directory listing. For example, if you found yourself having to keep typing in the command

cd /var/spool/users/home/mail/root/sun
to save all that typing you can specify a "shortcut" word that automatically does just that. Cool eh?

So to tell the shell that you want to use the word "checkmail" to do the command

cd /var/spool/users/home/mail/root/sun
you would add to the list:

alias checkmail='cd /var/spool/users/home/mail/root/sun'
Then you could type the alias checkmail and hey works!!

Of course many people like to issue aliases to accommodate their typographical errors; i.e.,

alias eamcs='emacs'
alias emcas='emacs'
Personally I think this is a bad idea, and you should learn to type more accurately!

The next section we shall look at is how to tell the shell which programs to run when it is suitable to run them. In my .bash_profile file I have among the following:


This is the section that we shall be concentrating upon setting these variables. Common variables that have not been set are ones like "EDITOR" and "MAIL". These variables are common to the user that is currently logged in, meaning that different values can be specifies for each user. The variable

specifies the editor to use when editing files. This variable is usually called from programs such as Pine and Cron, but it can be very useful when writing shell scripts.

To set the variable, one has to add it to the "export" list, like this:


Exporting a variable releases it into the environment, rather than keeping it within a single program. Exporting is done, so that many different programs can use the same variable name with the same value, get it :-).

Once added to the export list, save the file, and exit your editor. So, now that we have defined a new variable, the next thing to do is to tell Bash, that it is there. To do this, you must "source" the file. This is a bash builtin that re-reads the file. You can either type this in, in one of two ways. Either you can specify

source filename
or you can specify a "." thus:

. filename

And that will then active your new added variable. Well, thats it for this section....

Setting up and Using Crontab

Do you ever find yourself repeating common tasks throughout the day, and wished that there was some sort of program that would automate it all for you? Well, look no further, Mr. Cron is here :-)

Cron is a scheduling program, and even more specifically it is known as a daemon. By daemon, I do not mean that it is a nasty creature with two horns!! A daemon is simply a program that runs in the background waiting for instructions. When it receives them, it executes them and when it has finished, it goes dormant again.

Cron is usually started when you switch to one of your run-levels. However, just to make sure it has started, issue the following command:

ps ax | grep crond

If you get a response similar to:

root       311  0.0  0.7  1284  112 ?        S    Dec24   0:00 crond
root       8606  4.0  2.6  1148  388 tty2     S    12:47   0:00 grep crond

Then cron has started, and you are ready to use it. If you don't get "crond" returned, then you must start the daemon, by typing


Cron is particularly useful when you find yourself needing to run backup and general maintenance programs. To tell cron when to run a program, you have to fill out several fields. Each separate program that is scheduled via cron is put into a file known as a crontab file. The fields are defined as the following:

Min	Hour	DOM	Month	DOW	User	Cmd

And a description of their input values are summarized in the table below:

Min Specifies the minute on or past the hour. Values range from 0 to 59.
Hour Specifies the hour (Military style) that the script should run at. The range is from 0 to 23 where "0" is Midnight
DOM This is the Day of Month, that you want the command run on, e.g. to run a command on the 23th of each month, the DOM would be 23
Month Specifies the month to run the script in. Values range from 1 to 12, where "1" is January and "12" is December. Or it can be specified using the first three letters of the month, e.g. May
DOW Specifies the day of the week, either as a numeric value of 0 to 7 (0 and 7 are both Sunday) or as the name of the week (using first three letters only), e.g. Mon
User Indicates who is running the command
Cmd The path and name of the script/program to be run

You can use a "*" (without the quotes) in any of the time fields to mean "every minute", "every hour", etc.

So, with the above descriptions in mind, the following examples are all valid:

01 * * * * root /usr/bin/script 	"This command is run at one min past every hour"
17 8 * * * root /bin/mail 		"This command is run daily at 8:17 am"
17 20 * * * root /usr/bin/fetch 	"This command is run daily at 8:17 pm"
00 4 * * 0 root /bin/qweb	 	"This command is run at 4 am every Sunday"
* 4 * * Sun root /usr/bin/file2rpm 	"This command is run at 4 am every Sunday"
42 4 1 * * root /usr/bin/squidlog 	"This command is run 4:42 am every 1st of the month"
01 * 19 07 * root /usr/bin/xman 	"This command is run hourly on the 19th of July"

See how easy it is? :-). Cron also accepts more sophisticated time specifications: run "man 5 crontab" for an explanation of these.

Of course this is all very well, but I have not told you where to put any of your cron entries. So.........hang on there, reader.

The most common version of cron installed on linux systems is "vixie-cron", and so in the "/etc" folder should be a file called "crontab". If you have specified the environment variable EDITOR (see the above section) then you can simply type in:

crontab -e

And that will load the file into your text editor

If you did not open it using the above command, then open it using a text editor of your choice and you should find something that looks like the following


# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

The SHELL variable indicates the current shell that we are using

The PATH indicates the path to the most common programs

The MAILTO option indicates to whom the output of the cron result (i.e. whether it has worked or not) and any output from the program is to be mailed. If you find that it is annoying, then you can delete this variable.

The section below "#runparts" is supposed to work so that in the folder "/etc/cron.daily" for example, whatever script is in there gets executed daily. However, for some strange reason, it has never worked well for me, and I have since found it easier to specify my own cron list.

So, to add the above examples to our crontab, it is just a matter of copying and pasting them in:


# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

#Custom Crontabs -- Put in by Thomas Adam
01 * * * * root /usr/bin/script 	
17 8 * * * root /bin/mail
17 20 * * * root /usr/bin/fetch 	
00 4 * * 0 root /bin/qweb	 	
* 4 * * Sun root /usr/bin/file2rpm 	
42 4 1 * * root /usr/bin/squidlog 	
01 * 19 07 * root /usr/bin/xman 	

Then save the file. Now the last thing we have to do is to tell cron that we have edited the file. That is done, with the following command:

crontab -u root /etc/crontab

And thats it...just sit back and wait..... You should find that by now your workload has diminished by about 25% or so!!!

Cron also has the ability of allowing and denying certain users who are allowed to use cron. To implement this, two files called cron.allow and cron.deny have to be created in the folder "/etc".

These files work in the following way. If for example you wanted nobody to have access to cron, then you would add the line "ALL" to the cron.deny file. If you wanted only certain people to use cron then you would add their username to the cron.allow file.

Rather than having to edit the file each time, I find it much easier to use the following command:

cat username >>/etc/cron.allow

Thats all there is to it....have a go and see what you think......!?!

Closing Time

Well folks, thats it for this month. I had hoped to do more, but unfortunately school work had intervened yet again!! I would really appreciate some feedback, general comments, hints as to articles, etc. Armed with this information I can then go about "making linux just that little more fun" :-)

I am now off to go and teach piano, do some Geography revision (yay) and then maybe continue working on some of my ongoing "bash script projects". After which, I might even be able to get some sleep. who knows?????

In the meantime however, I wish everyone...."happy Linuxing"

Send me comments....

Any comments, suggestions, ideas, etc can be mailed to me by clicking the e-mail address link below:

Thomas Adam

Copyright © 2001, Thomas Adam.
Copying license
Published in Issue 66 of Linux Gazette, May 2001

[ Prev ][ Table of Contents ][ Front Page ][ Talkback ][ FAQ ][ Next ]