Handling Shell Script Interrupts

A Real Screen Shot

If you do much shell scripting, then handling shell interrupts is something you should consider.  As a user is interacting with your script, they may decide to interrupt it by typing Ctrl-C, for example.  Typically this will interrupt your shell script execution, forcing it to exit.

Depending on what your shell script is doing, this could leave behind temporary files, or leave other files in a broken state.  It would be useful if you could trap the interrupt, and handle it safely, before exiting the script.
This can be achieved on most shells using the ‘trap’ command.  The trap command takes the following syntax:

trap [OPTIONS] [[ARG] SIGSPEC ... ]

The ARG is the command to be executed on signal delivery, while SIGSPEC is the name of the signal(s) to trap.  Options include -h for help, -l to list signal names, or -p to print all defined signal handlers.

For example, to always return a ‘user aborted’ error code, the following line in your script could be used.  Whatever value given to $exit_user_abort would be returned.

trap 'echo "`basename $0`: Ouch! User Aborted." 1>&2; exit $exit_user_abort' 1 2 15

The numbers 1, 2 and 15 at the end of this example define which interrupts we’re interested in trapping.  These numbers correspond to different kinds of interrupts.  A short list is given here, but you can use ‘trap -l’ for a complete list.

Signal Number	Signal Name	Explanation
0	EXIT	exit command. Script has executed successfully.
1	HUP	Hang Up. The user session has disconnected.
2	INT	Interrupt.  Ctrl-C (or other shell interrupt signal) has been given.
3	QUIT	Quit.  Ctrl-\ (or other shell quit signal) has been given.
6	ABRT	Abort signal.
15	TERM	Terminate.  Kill command has been issued against your script.

If your trap runs several commands, it’s possibly neater to call a shell function than list the commands in-line, as above.  For example:

trap funcname 1 2 15

funcname
# Function to handle interrupts
{
echo "`basename $0`: Ouch! User Aborted." 1>&2
exit $exit_user_abort
}

Ini files and Apache Commons Configuration

Trashing old software

The project I’m currently working on uses a simplistic object store for persistence.  The original authors, in their collective wisdom, decided that whenever something needed to be saved they would save it to a hashtable, and use Java serialization to save that to a file.

In a way I can see why they did. It’s a quick way of getting a simple to use object store.  The project has been through several revisions since, but the data store stayed the same.  It should have been replaced with something more robust a long time ago.  I’ll explain more after the jump …

Automatically Unmount Network Shares on Ubuntu

Hard disk dissection

I’ve mentioned before, how I mount shared drives in Ubuntu both at home and at work.  While this is quite useful, it seems the default setup for Ubuntu stops the network interface before disconnecting these drives.  This results in Ubuntu hanging for a while on shutdown while these drives time out.  After the jump we describe how to solve this problem.

FARTing Around

INBOX 0: Tarditas et procrastinatio odiosa est

I’ve recently become aware of Getting Things Done, and have been attempting to practice it for the last six weeks.  In many ways, it is very similar to what I had been doing previously.  You could call my method a lightweight GTD, and it’s based on the FART mnemonic.

For any item that crosses my desk, be it email, IM, memos, or stickies, I follow the same basic triage process.  Four directives (File, Act, Redirect or Trash) are applied based on a few simple considerations.  These are as follows:

• Do I need to refer to this item again?

If so, file it somewhere easily searchable such as a mail folder, content management system, Wiki, etc.  Remove the item from your In-box to the file location.  Continue to consider the other questions.

• Do I need to act on this?

If so, add a to-do to your to-do list.  Prioritise and schedule work on the action using your to-do list.  Remove the item from your In-box by Filing, Redirection, or Trashing.

• Am I the best person to work on this?

If not, redirect or delegate it to someone else.  You may, if you feel you need to, add a reminder to your to-do list to follow up with the delegate.

• Trash it, you’re done.

By now, you’ve filed the item if necessary, decided to act on it, or delegated it.  What other possible action can you now take?  You have extracted all value from the item, so the only other option is to remove it from your In-box.  If you have not done so already, or filed the item to a folder, move the item to the trash.  You are now done with processing your incoming items.  All that remains is to tackle your to-do list.

Repeat as necessary, and you will soon find that heap of email shrinking.  In-box 0 is not an impossible goal.  All you need to do, is think outside the In-box!

Pre-Merge Formatting

Merge Right

A problem with formatting code on a branch, is when you come to merge it back to the trunk, you end up having to work thorough lots of file changes which are really only formatting changes.  The larger your project size, the more work this involves.  I was faced with a similar task recently.

While editing file by file, I usually do the Ctrl-A Ctrl-Shift-F combo to ensure the file is formatted according to our corporate standards before saving any edits.  Since much of the code I touched on the branch was formatted under a different standard, and I touched a lot of files while introducing log4j logging, the end result was heading for a hairy merge.  What I really needed was a way to bulk format both the branch and the trunk versions of the code-base.

Luckily, I realised that that same formatter embedded in Eclipse can be used to bulk format Java source.  Here’s how …

Howto: Pause a Shell Script

Computer Data Output

File this one under “Another Nifty script-let”.  The problem this time is getting a shell script to pause for user input.  What I needed was a way to make a script stop, saying “Hit a key to continue..”, wait for the user to hit a key, then continue the script execution.  Here’s how:

Technical Marketing

Tag Cloud

It saddens me sometimes to see videos like this.  While the rest of us chuckle, we fail to learn the lesson, that users don’t share our world view of software.

As a Software Engineer, I am too well aware of our industries penchant for technical terms.  Yet the fact remains that you can use the internet without knowing what a “browser” is, just as well as you can drive a car without knowing what a “limited slip differential” is.

Life Lesson: The More You Write, The Less They Read

Fall-2006

Since I realised this, life has become somewhat easier.  Being a Software Engineer means that I often have to communicate with people with non-software backgrounds, such as Clients, Management or Marketing.  A difficulty we have in communication, are the multi-letter acronyms (MLAs) and other jargon which is prevalent in software, and other technical fields I imagine.

When it comes to documentation, the initial reaction of a reader who doesn’t understand what you’ve written, is to claim that insufficient information was present (whether this is true or not).  The typical responce from the Engineer is to provide even more MLA and jargon loaded text.  Essentially providing a larger maze of documentation for the reader to get lost in, resulting in a request for more documentation, and the cycle goes on …

The solution to this conundrum is not more documentation, but more consice and succinct documentation.  Avoid MLAs and jargon where possible.  Where this is not possible do your best to explain it simply.  Know your audience, and speak in terms they can understand.  Do your best to keep it short and to the point.

Finally if all else fails.  Suggest a GIYF.

How to change date formats on Ubuntu

The Date Stamp

In order to change the system date format on Ubuntu, you need to know a little about where the date format is coming from.  Regional settings, such as date and time formats, as well as language, sort order, etc. are specified in files called locales.  A locale contains the rules specifying how dates and times are formatted, amongst other settings.

The Perfect Build Setup – Hudson

Introduction.

I have had a passing acquaintance with Hudson for some time, but it is only recently that I’ve had to get down and dirty with it.  For one reason or another, much of the build infrastructure work for my current project has fallen on me.  This has allowed me to become much more involved with Hudson on a daily basis, and I have to say I’m loving it.

Hudson is a continuous integration environment.  We have configured it to check code out of our subversion repository on a regular basis, run the build scripts, gather the cobertura code coverage, junit test reports, findbugs reports, etc., and have these metrics published and trended over time.  I think I can speak for my team when I say, we’ve found it a boon to be able to regularly build our system in a clean environment, and gain such insight into our code quality.

So without further ado, I present instructions to allow you to set your own build system up in 20 minutes or less.