Last week I was asked how to handle running a shell command from Ruby, with the added requirement that if the command took longer than a certain time it should time out.

Running commands from ruby is easy, and you should watch the video of my Ruby Manor talk for some of the gory details.

But, is there a simple way to time-out a shell script using ruby? Well, you could probably write some heady threaded code that does it. But don’t. This is what the shell is for.

The usual Unix caveat applies: in the seventies, under the influence of prog rock, speed and the Californian sun, a bearded fellow already wrote the exact tool you want. And that tool has no doubt shipped with every Unix ever since. And everyone but you uses it daily.

But, this time, I couldn’t find that tool. There must be one. Anyone know of it?

Anyway, this is what I did:

#!/bin/bash

# timeout
# Usage: timeout timeout_in_seconds command [args]
# Example: timeout 120 wget http://www.slowserver.com 

timeout=$1
command=$2
command_args=${@:3} 

$command $command_args &
pid=$!
( sleep $timeout && kill -9 $pid ) &> /dev/null

wait $pid &> /dev/null
exitcode=$?
exit $exitcode

We launch the main command in the background; then, we launch a second command that sleeps for the requested timeout before attempting to kill the first one; then, we wait for the first command to finish (either of its own accord or thanks to a kill signal), returning its exit code as our own.

It’s brutish and dumb, but for most cases this simple approach works.

Be careful if your machine is going through PIDs like billy-o -you could end up sending the TERM signal to the wrong process -, but in general use that shouldn’t be a problem.

You could make it safer by storing start time and PID and making sure they both match, or something similar. Left as an exercise to the reader, as us lazy folk say.

A few bash things you may not have seen before: the special parameters !, @ and ?, wait and bash parameter substring expansion.

$! expands to the PID of the most recently executed background command, and $? expands to the exit status of the most recently executed foreground command.

“$@” is equivalent to “$1″ “$2″… I use the ${parameter:offset} notation to grab a slice that array.

wait is a useful shell built-in that takes any PID, waits for it to finish and returns its exit code.

Much more detail, of course, lurks in the bash man page – I still find I look up these cryptic characters or copy them from an existing script.

There’s a standard tool that does this better, right?

This is what I came up with.

The script takes one argument – the term to search on – and creates a sqlite3 database in the current directory containing all the tweets that the twitter search API returns for that term.

It requires datamapper and twitter_search gems to be installed.

Have at it, make it better, bend it to your twitter-slurping needs.

You’ll need a room, account, etc. in Campfire; you’ll need to compile this version of dumb-frotz; and you’ll need a zcode file to play – plenty of those at the Interactive Fiction Database.

I only wrote about this because @lazyatom called me a genius for doing it. Which was nice.

Have fun.

What with a recent endorsement from Martin Fowler and this graph – spotted on Jason Huggins’ blog – it seems that ruby and rails are truly gaining the popularity they deserve.

I think that the biggest advantage of using mock objects is that your tests run quicker. I find that the quicker I can run all the tests, the braver I become in fixing any broken windows that have crept into the code. But there are other significant advantages too: design decisions can be defered until you have more knowlege about the domain; classes tend to end up less tightly coupled; girls throw themselves at you in the street. Well, perhaps two of those three things are true.

An example from our codebase using the Schmock mock objects library that we developed while writing our code here.

Although we’re programming in Rails, our controller layer and model layer are separated by some service objects – one of which handles our wiki implementation. To test the wiki controller, we mock out the actual wiki using a SchMock:

class WikiControllerTest < Test::Unit::TestCase

In the setup method we create the mock_wiki and inject it into the application controller from which everything that uses it can access it.

  def setup
    @mock_wiki = SchMock.new
    ApplicationController.wiki = @mock_wiki
    @controller = WikiController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
end

At the end of every test we verify that the mock_wiki has had all its expectations fulfilled.

  def teardown
    @mock_wiki.__verify
  end

Now the real meat of the test. We want to make sure that if we try to edit a non-existing page that we’re redirected to the ‘new’ action. We tell our mock_wiki to expect a call to page_exists? with a parameter ‘nonexistent’ and when it gets it to return false.

I find this simpler than using the built-in fixtures functionality in rails to set up the database to a known state, because the fixture appears right there in the code rather than derived from two-step removed database tables and I don’t have to remember to delete any pre-existing state from the database. It also runs much, much quicker.

  def test_should_redirect_to_new_page_form_if_asked_to_edit_nonexisting_page
     @mock_wiki.__expects(:page_exists?).with('nonexistent').returns(false)
     get :edit, { :page => 'nonexistent'}
     assert_redirected_to :action => 'new', :page => 'nonexistent'
  end
end

I think my life-expectancy has been greatly improved through the use of mock-objects and I thank the good chaps who wrote and promoted the original mock-objects – people like Steve Freeman, Nat Price, Ivan Moore and Joe Walnes – who write much more elegantly than me on the topic.