Semi-Reliable Periodic Commands

Impromptu

cron is great. Using cron, you can schedule commands to be run at regular intervals or at specific times. One of the major drawbacks of cron is that it doesn't generally keep state regarding job's status. If a job is scheduled to run at midnight, but the system is powered down at midnight, the command will never be run.

There are a few solutions out there to take care of this shortcomings, but many are designed for system-wide use only. What if you don't want to intermingle your personal jobs with the system-wide ones? Here is a fairly simple script that works as a wrapper, providing a little insurance to help make sure jobs get run.

#!/bin/bash

export P_ENV=~/.profile
export P_TRACK=~/.p_track

if [ -e "$P_ENV" ]; then
 . $P_ENV
fi

case "$1" in
 h) 
  export P_NOW=$(date +%Y-%m-%d-%H)
  ;;
 d)
  export P_NOW=$(date +%Y-%m-%d)
  ;;
 w)
  export P_NOW=$(date +%Y-%U)
  ;;
 m)
  export P_NOW=$(date +%Y-%m)
  ;;
 *)
  echo ERROR: Term not specified. Must be one of h, d, w, m .
  exit 1
esac

if [ -z "$2" ]; then
 echo ERROR: Command to run not specified.
 exit 2
fi

export P_TAG=$(echo $2 | sed -e 's/[^A-Za-z0-9]/-/g')
export P_FILE=$P_TRACK/$P_TAG-$P_NOW

if [ -e "$P_FILE" ]; then
 exit 0
else
 rm -f $P_TRACK/$P_TAG*
 echo Executing $2 at $(date)
 $2 $3 $4 $5 $6 $7 $8 $9
 echo Done
 
 if [ "$?" -eq "0" ]; then
  touch $P_FILE
 fi
fi

The script has 4 operating modes. It can help ensure command are run hourly, daily, weekly, or monthly. It uses empty files in a configurable directory (~/.p_track by default) to keep tabs on the last time the command was run. Entries in the tracking directory are only created if the command run returns exit status 0 (no error.)

To use this wrapper, place it and a period (h for hourly, d for daily, and so on) in front of commands in your crontab like so:

*/20 * * * * ~/bin/periodic h ~/bin/command param1 param2

The above will check to see if the command needs to be run every 20 minutes, but will only execute it every hour. The advantage of wrapping individual commands instead using periodic command directories (check out the run-parts command) is less administrative overhead.

Note: The "real" periodic command is generally used to run system-wide periodic commands, often stored in /etc/periodic. UNIX-y systems tend to use other mechanisms and directories to do something similar.

Update 1: Changed the script from a group of if/elif to case (thanks for pointing that out Dave) and added a quick import of .profile or another file to set up environment.

Flash Objects and the Z-Index

... On my Mac using Safari the drop down menus appear. When I move my cursor down on the drop down the rest of that drop down disappears In IE the drop down menus go only as far as the the top of the Flash file. I am not sure if it does the same in Mozilla. Anyway to circument this? Perhaps I could just do a pop-up page? - Michael

Yes! This is easy. First, you'll need to add a param tag to your object tag. Set the name to wmode and the value to transparent.

<param name="wmode" value="transparent" />

Then, force your Flash object to be below everything else by changing its z-index to 0. For the unfamiliar, think back to Geometry class in high school. You had X, Y, and Z axis. In the user interface world, the Z axis values specify how objects are stacked, and typically don't deal with perspective as you would see in a 3D game.

For some reason, applying z-index directly to a Flash object doesn't work properly. Wrap your Flash object in a div, and apply the z-index to it.

<div style="z-index: 0">...</div>

That's all there is too it!

Update 1: Unfortunately, the above code only works for Internet Explorer! The object tag is for IE only. Most embeded Flash content is wrapped with two tags in order to support both IE and other browsers. These tags are the object and embed tags. In order for this fix to apply to all browsers, modify the embed tag as well, adding the wmode property with a value of transparent.

Bad Programming

Rant

The self-checkout kiosk at the local supermarket blocked, waiting for employee input instead of giving me errors. Why? Bad programming.

Planet keeps brining up my old posts if I modify them (typically to correct errors). Why? Yup. Bad programming.

Bad programming doesn't necessarily mean bugs and buffer overflows. It also means bad predictions about program flow. If a narrow sequence of events is all code can accommodate without some easy and automatic method to attempt recovery and/or to bring things back on track, its badly programmed.

Programmers aren't mind readers, but they need to consider the "what ifs". When a program behaves in a manner that is just plain stupid, its probably badly designed!