Tech Tips
The version of KPilot that comes with Ubuntu/Kubuntu Edgy Eft does not work with many Palm devices, such as the Palm TX, many Treo phones and others. Although many people are complaining about the difficulty of setting up the USB port, this tip doesn't address that particular issue. Even if you get the USB port working (I use a network sync, so it doesn't matter to me), you'll encounter other problems. For example, in many cases, KPilot copies the records from your Palm but erases the records from your Palm in the process.
At the time of this writing, the good folks at Ubuntu have not yet seen fit to update KPilot. There's no need to wait though. You can download the latest KPilot, compile and install it yourself. The version I downloaded works fine with my Palm devices.
You must have the KDE and Qt development libraries to compile KPilot, so you will need to install kde-devel at the very least. You also need cmake, which isn't installed by default in Ubuntu. You need to install the latest version of pilot-link separately as well, and compile it, first. In this example, I installed pilot-link in /usr/local/src/pilot-link-0.12.1. I also set the following environment variables for my platform (this is optional and may not apply to your platform):
export CFLAGS="-march=athlon64 -O2 -pipe" export CXXFLAGS="${CFLAGS}" export CPPFLAGS="${CFLAGS}" export CXX="g++"
Here are the commands to download, make and install KPilot:
cd /usr/local/src svn co svn://anonsvn.kde.org/home/kde/branches/KDE/ ↪3.5/kdepim/kpilot/ cd kpilot ./configure --prefix=/usr --with-pilot-link=/usr/ ↪local/src/pilot-link-0.12.1 make -f Makefile.cmake make -f Makefile.cmake install
If you already have KPilot running, you need to exit, and you may even have to kill the dæmon with the command:
killall kpilotDaemon
Restart KPilot, and now you should be able to sync without problems. If you want to keep up to date with the latest changes, you can update the source code with the following command (obviously, you need to configure and install again afterward):
svn update kpilot
—Nicholas Petreley
Much open-source software for Linux has good monitoring commands for observing process activity. Some of the commands do not have graphical user interfaces, and in other cases, administrators prefer to use the command line. Monitoring the progress of an activity is a continuous task.
The Linux watch(1) command ( linux.about.com/library/cmd/blcmdl1_watch.htm) is a useful tool for monitoring progress. It allows users to run a command and watch the output in a terminal window. It can execute the monitoring command at regular intervals and show differences (option -d) between successive updates.
Many Amanda ( amanda.zmanda.com) users, myself included, use the watch command to observe the Amanda backup progress. The Amanda status command amstatus ( wiki.zmanda.com/index.php/amstatuscommand) can be run with the watch command every minute to monitor the progress for each filesystem being backed up:
watch --differences=cumulative ↪--interval=60 amstatus backupconfigg
The above command watches the backup progress for the Amanda configuration backconfig.
Another use for watch is to watch memory usage in a system:
watch cat /proc/meminfo
—Paddy Sreenivasan
The following tip comes courtesy of Foundations of PEAR: Rapid PHP Development by Nathan A. Good and Allan Kent, published by Apress ( www.apress.com/book/bookDisplay.html?bID=10181).
This tip shows how to generate strong passwords using a PEAR package called Text_Password. To use the code shown in this tip, you need to have PEAR installed along with PHP, and you need to install the Text_Password package. To install the Text_Password package, type:
pear install text_password
The Code:
The PHP script that creates the password looks like this:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Password Example</title> <style> li { font-style: italic; } </style> </head> <body> <?php // require the Text_Password package // to be included in the page require_once "Text/Password.php"; ?> <p> <strong>Here is a pronounceable password, defaulting to 10 characters:</strong> <br /> <em><?php echo Text_Password::create(); ?></em> </p> <p> <strong>Here are 5 unpronounceable passwords, with a length of 15 characters each:</strong> <br /> <ul> <?php $passwords = Text_Password::createMultiple(5, 15, 'unpronounceable'); foreach ($passwords as $password) { ?> <li><?php echo $password; ?></li> <?php } ?> </ul> </p> </body> </html>
The Results:
When the script is executed, it generates output very similar to that shown here. Of course, because the passwords are generated randomly, your actual results will differ slightly:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Password Example</title> <style> li { font-style: italic; } </style> </head> <body> <p> <strong>Here is a pronounceable password, defaulting to 10 characters:</strong> <br /> <em>vumaechoud</em> </p> <p> <strong>Here are 5 unpronounceable passwords, with a length of 15 characters each:</strong> <br /> <ul> <li>E_3uYlRxYY2n%pd</li> <li>Ghn0Q@XZr%DBvDe</li> <li>0tAUoGoJR7C1zo2</li> <li>f#EA5jHIZmjaW8O</li> <li>1cbc7fhL@d#RHWM</li> </ul> </p> </body> </html>
How It Works:
The Text_Password::create() method can be called statically. It returns a pronounceable password with a default length of ten characters, as shown in the output.
The Text_Password::createMultiple() method, also called statically, can accept parameters that allow you to specify how many passwords you want returned, the number of characters in each password and that they be either pronounceable or unpronounceable, depending on the desired complexity for the password. Passwords that are unpronounceable have numbers and punctuation marks in them.
Using the Text_Password package, you quickly can write PHP scripts that allow your application or Web site to have the capacity to generate passwords.
—Nathan A. Good and Allan Kent
This tip comes courtesy of Linux Journal columnist Dave Taylor and No Starch Press.
Any script that reads or appends to a shared data file, such as a log file, needs a reliable way to lock the file so that other instantiations of the script don't step on the updates. The idea is that the existence of a separate lockfile serves as a semaphore, an indicator that a different file is busy and cannot be used. The requesting script waits and tries again, hoping that the file will be freed up relatively promptly, denoted by having its lockfile removed.
Lockfiles are tricky to work with though, because many seemingly foolproof solutions fail to work properly. For example, the following is a typical approach to solving this problem:
while [ -f $lockfile ] ; do sleep 1 done touch $lockfile
Seems like it should work, doesn't it? You loop until the lockfile doesn't exist, then create it to ensure that you own the lockfile and, therefore, can modify the base file safely. If another script with the same loop sees your lock, it will spin until the lockfile vanishes. However, this doesn't in fact work, because although it seems that scripts are run without being swapped out while other processes take their turn, that's not actually true. Imagine what would happen if, right after the done in the loop just shown, but before the touch, this script were swapped out and put back in the processor queue while another script was run instead. That other script would dutifully test for the lockfile, find it missing and create its own version. Then, the script in the queue would swap back in and do a touch, with the result that the two scripts both would think they had exclusive access, which is bad.
Fortunately, Stephen van den Berg and Philip Guenther, authors of the popular procmail e-mail filtering program, include a lockfile command that lets you safely and reliably work with lockfiles in shell scripts.
Many UNIX distributions, including Linux and Mac OS X, have lockfile already installed. You can check whether your system has lockfile simply by typing man 1 lockfile. If you get a man page, you're in luck! If not, download the procmail package from www.procmail.org, and install the lockfile command on your system. The script in this section assumes you have the lockfile command.
The Code:
#!/bin/sh # filelock - A flexible file-locking mechanism. retries="10" # default number of retries action="lock" # default action nullcmd="/bin/true" # null command for lockfile while getopts "lur:" opt; do case $opt in l ) action="lock" ;; u ) action="unlock" ;; r ) retries="$OPTARG" ;; esac done shift $(($OPTIND - 1)) if [ $# -eq 0 ] ; then cat << EOF >&2 Usage: $0 [-l|-u] [-r retries] lockfilename Where -l requests a lock (the default), -u requests an unlock, -r X specifies a maximum number of retries before it fails (default = $retries). EOF exit 1 fi # Ascertain whether we have lockf or lockfile # system apps if [ -z "$(which lockfile | grep -v '^no ')" ] ; then echo "$0 failed: 'lockfile' utility not found in PATH." >&2 exit 1 fi if [ "$action" = "lock" ] ; then if ! lockfile -1 -r $retries "$1" 2> /dev/null; then echo "$0: Failed: Couldn't create lockfile in time" >&2 exit 1 fi else # action = unlock if [ ! -f "$1" ] ; then echo "$0: Warning: lockfile $1 doesn't exist to unlock" >&2 exit 1 fi rm -f "$1" fi exit 0
Running the Script:
Although the lockfile script isn't one that you'd ordinarily use by itself, you can try to test it by having two terminal windows open. To create a lock, simply specify the name of the file you want to try to lock as an argument of filelock. To remove the lock, add the -u option.
The Results:
First, create a locked file:
$ filelock /tmp/exclusive.lck $ ls -l /tmp/exclusive.lck -r--r--r-- 1 taylor wheel 1 Mar 21 15:35 ↪/tmp/exclusive.lck
The second time you attempt to lock the file, filelock tries the default number of times (ten) and then fails, as follows:
$ filelock /tmp/exclusive.lck filelock : Failed: Couldn't create lockfile in time
When the first process is done with the file, you can release the lock:
$ filelock -u /tmp/exclusive.lck
To see how the filelock script works with two terminals, run the unlock command in one window while the other window spins trying to establish its own exclusive lock.
Hacking the Script:
Because this script relies on the existence of a lockfile as proof that the lock is still enforced, it would be useful to have an additional parameter that is, say, the longest length of time for which a lock should be valid. If the lockfile routine times out, the last accessed time of the locked file could then be checked, and if the locked file is older than the value of this parameter, it safely can be deleted as a stray, perhaps with a warning message, perhaps not.
This is unlikely to affect you, but lockfile doesn't work with NFS-mounted disks. In fact, a reliable file locking mechanism on an NFS-mounted disk is quite complex. A better strategy that sidesteps the problem entirely is to create lockfiles only on local disks.
Excerpted with permission from the book Wicked Cool Shell Scripts: 101 Scripts for Linux, Mac OS X, and UNIX Systems by Dave Taylor, published by No Starch Press ( www.nostarch.com/wcss.htm).
Paddy Sreenivasan is VP of engineering and cofounder of Zmanda.
Nathan A. Good lives in the Twin Cities area in Minnesota. He is a software developer, system administrator and author. He has written and co-written several books and articles on open-source technologies.
Allan Kent is a born and bred South African and still lives and works in Cape Town. He has been programming in various languages and on diverse platforms for more than 20 years. He's currently the head of technology at Saatchi & Saatchi Cape Town.
Dave Taylor is a longtime UNIX and Linux geek and runs the popular www.AskDaveTaylor.comtech support blog. His book Wicked Cool Shell Scripts can be found at www.intuitive.com/wickedand the entire library of scripts at www.intuitive.com/wicked/wicked-cool-shell-script-library.shtml.
Linux Journal pays $100 for reader-contributed tech tips we publish. Send your tips and contact information to techtips@linuxjournal.com.