Linux Blog

While not exactly a shell script, I figured it would be worthy to post something rather than nothing and technically it is a script none-the-less.
I was experimenting with Asterisk AGI scripts and needed a project. I decided that an IP address lookup would be a good one. Sometimes my dynamic IP changes but my dynamic DNS doesn’t update. With this script, I should be able to dial into my Asterisk machine and get it to tell me the IP address. At least, that’s the plan.

So, you just finished that killer script and the first thing you want to do is write that man page for it right? Not exactly? What do you mean?
Writing a man page isn’t that hard and will give your users an idea of how to use a script.

Here is a basic template for creating your own man pages:

.\" This is a comment
.\" Contact Owen@thelinuxblog.com
.TH man 1 "21 June 2009" ".1" "Man Page Example"
.SH NAME
Man \- Example Man Page
.SH SYNOPSIS
Example Man Page
.SH DESCRIPTION
This is an example of a man page.
.SH OPTIONS
No options for this man page
.SH SEE ALSO
man(1), groff(1), man.config(5)
.SH BUGS
No known bugs for this template, except you might want to replace the quotes if you copy from my blog.
.SH AUTHOR
Owen (owen@thelinuxblog.com)

When you’re done with the gruelling task of writing documentation (which your users won’t read or thank you for) just plop it the correct man section in /usr/share/man
That’s all there is to it!

This week on Shell Script Sundays I’ll show you how to add a service to Fedora. This is very useful if you don’t happen to use yum for every service you want to run, and xinetd doesn’t really work for you.

Firstly there are three main parts to a Fedora service script. Start, Stop and Restart. They are pretty much self explanatory, but you don’t have to worry about the restart action since all it does is stop’s and then starts the service.

Now that you have a template for the script, you will want to modify it for your service. You need to keep the header at the top. This is how the Fedora Knows about your service. The three numbers indicate what order the scripts should start up and shut down in. The first seems to be a identification number and the other two are the startup and shutdown order. These can be adjusted depending on when you want the service to start up.Once you are done modifying the script put the script in /etc/init.d/

To make sure it works you can call it with service using the following actions:

service start
service stop
service restart

If all of the actions work, you are ready to add the service to the system. If you use the setup command as root it seems to do this step for you, but if you just want to add the service quickly without bothering to scramble through configuration menu’s you can do the following:

chkconfig --add[script name]

If you want the service to start automatically at boot up you can use ntsysv. For more information read my post on Managing Services on Fedora

As you may know if you are a regular reader I own a Toshiba Tecra M2. One of the things that annoyed me was I had to turn the brightness up every time my computer came out of standby mode. A fix for this is to adjust the brightness every time the computer comes out of standby mode.

The script is intended to be run under cron. I have mine set up to suspend after 5 minutes of the lid being closed.

The script first checks the current brightness. If the brightness is currently 1 or 7 it adjusts the mathematic operation so that when the laptop is opened the brightness is adjusted. Basically if the brightness is one, it adds one. If the brightness is 7 or any other value it subtracts one. This is currently working out quite well for me. I don’t know how useful this is to any body else, unless you happen to have a Toshiba that is doing the same thing but it should give you a good overall idea of how to perform basic mathematic operations in bash.

Earlier this week I made a script that logs into cPanel to check statistics. Basically if you have a webhost that runs cPanel and you wish to log into cPanel for some reason then this script is for you. Once you are logged in you can basically do anything you would want to do. For example my specific use was to log into my cPanel nightly and parse some data provided by AWStats. But with some modification this script could automate anything you can do by hand.

Since this is more of a web project for me I decided to write my cPanel login script in PHP. I found a PHP class to login here. curl is used to fetch the URL’s and I parse the data using PCRE regular expressions. The statistics code is still very basic but I thought I would post it for those interested and what better place then The Linux Blog’s Shell Script Sundays column?

Onto the script.

It consists of three scripts each with their own purpose in run time. They are as follows:

cPanel.php – This script does all of the dirty work in connecting to cPanel and fetching the pages. I modified this from the original a little
class.mysql.php – Just a generic data base handler. MySQL configuration information is stored in here.
login.php – This is the script that starts off the process. I named it login.php instead of index.php so that I do not have it run as the default page in my web browser. login.php also does all of the parsing of the data and is where the data gets inserted into the database.

To run the script edit login.php and then you can either put it in your PHP powered web server directory or run it from the command line by doing:

One thing that is for certain is that some people like performance. Running an operating system like Linux gives you choices right out of the box for scripting. This blog post will show the differences in times between Bash, PHP and Perl.

Basically what I have done is created three scripts, one in each language. Then I run them with the time tool to test out the execution time.

Here are the results of echoing 1-100000 out to /dev/null for each script:

People complain that Slackware is hard to use. I don’t believe that thats true. I don’t think that its any harder to use than any other Linux distribution. I also believe that there is perfection in simplicity. Believe me that it isn’t the easiest to set up but once its up it is actually easy to update and maintain once you learn how.

Despite popular believe Slackware does have good package management software. The main ones that come to mind are slapt-get, slackbuilds, pkgtools, swaret and slackpkg. Below is a small amount of information about each of them.

I’ve never myself used swaret so I don’t know too much about it other than its a package manager that manages dependencies. I also know that a new version will be released soon. If your interested in finding the best package management for Slackware you might want to check swaret out.

slapt is a mashup of the two words slack & apt. Those familiar with Debian or Ubuntu will know apt-get is at the heart of these systems, slapt-get is a clone of this system. Its been in Beta since its creation but works perfectly. There are graphical front ends for this software. I personally don’t use it because I can not find a fast repository in my area.

slackbuilds are kind of like the Gentoo package management. They are distributed with the source code on the Slackware DVD. They are basically scripts that help compile the source code. Its pretty easy to use, for more information visit: slackbuilds.org

pkgtools are the base of Slackware package management. Basically it is a suite of utilities that you can use to install, remove and upgrade software. The best source I’ve found for finding extra packages is linuxpackages.net.

My favorite for updating Slackware is slackpkg. It uses pkgtools to install and remove packages. It comes on the Slackware CD’s / DVD’s in the extras folder and is pretty easy to use. Basically you install it, select a mirror from the config file and then run:

slackpkg update

Once its finished doing its thing you can then do:

slackpkg upgrade-all

This will start a fairly lengthy process of downloading and installing all of the new packages. Other options are available such as options to install new packages, remove packages revert to vanilla system and many more. One thing I have to caution on is updating to current. Its not as easy as upgrading from release X to slackware-current all the time. This is due to the different versions of GCC, glib, solibs and various other types of libraries. Always read the UPGRADE.TXT or at least have a back up of all of your critical data before attempting to upgrade.

There are a lot of options, if your interested in running Slackware I suggest you try them all and then use the one you like. If you don’t want to run Slackware because another distribution suits you better try not to use the “I don’t use Slackware because its hard to maintain” card.

When designing a shell script it is important to make them easy to use but also to make it easily automated for deployment. One example of this that comes to mind is the NVIDIA installer. It has command line options to allow for deployment but also gives a nice interface for the end user.

To implement this “dialog” can be used for the user interface and “getopts” can be used for the command line options. The script may look something like:

#help functionhelp(){echo"Linux Blog - getopts and dialog example";
echo"Usage:";
echo-e"\t -h shows this help";
echo-e"\t -a [y/n][other] ANSWER (Yes, No or Other)";
}#show dialog to get the answers
showDialog (){dialog--yesno"Do you want to enter y?"550&& \
ANS="Yes was entered using dialog"||\
ANS="No was entered using dialog"
showAnswer;
}#actually show the answer
showAnswer(){echo$ANS;
}#check answer for command line processing
checkAns(){if["${OPT1}" == "y"]thenANS="Yes sent by getopts";
elif["${OPT1}" == "n"]thenANS="No was sent getopts";
elseANS="This: $OPT1 was sent by getopts";
fi#call showAnswer
showAnswer;
}#get the optionswhilegetopts"a:h" ARG;
docase"${ARG}"in
a)OPT1="${OPTARG}";;
h)HELP="TRUE";;esac;
done#see if help was enteredif["${HELP}"]then#display help and quithelp;
exit;
fi#if the options are emptyif[-z"${OPT1}"]then
showDialog;
else
checkAns;
fi

Keep this getopts and dialog post in mind next time your shell scripting. It will take a little extra time to implement but the result will be a user and sysadmin friendly script.