Archive for January, 2009

An unexpected use for urunner

Saturday, January 31st, 2009

I upgraded to KDE 4.2 yesterday (it is a big improvement; recipes are in the store), and I’ve spent a lot of today playing about with the new and old functions. In the process I managed to freeze plasma a couple of times, so the screen wasn’t responding at all except for the mouse pointer. That meant the usual way of quitting and restarting plasma wouldn’t work. It was much harder to get it to freeze this time than earlier, but just as frustrating to have to kill X and log in again (since I couldn’t run kquitapp etc with nothing responding).

However, I could log in at the console with no issue. From there I could run `urunner <<<”kquitapp plasma && plasma”` and the daemon would restart plasma for me within the session, so it had access to all the usual resources and I avoided having to Ctrl-Alt-Backspace. That was an unintended feature, but it was very handy a few times.

Introducing urunnerd

Tuesday, January 27th, 2009

urunnerd is a daemon for executing tasks within a user session, although the task may have been triggered from outside the session. This is useful for displaying user-visible notifications from a cron job (I have this after my backup job) or from SSH, or for any time you want to have a program run with access to all the resources of the user session. You can start it from your desktop environment’s autostart functionality or xinitrc and forget about the daemon.

The daemon looks for task files in ~/.cache/torun, executes them one at a time with sh and deletes the file afterwards. It also comes with a `urunner` script that reads from stdin and creates a unique task file in the current or a specified user’s directory. Creating the files manually works just fine too, and it skips filenames starting with “.” so you can write the task and move it into place when you’re done.

More details are in the README within the source. On the to-do list is looking into using inotify rather than polling, and probably fixing whatever bugs are assuredly there. I’ve been using it ok for a few days now, but it comes with the usual no warranty and may wreck your stuff (seriously). `make install` will drop it into ~/.local/bin by default, or I’ll be committing a GoboLinux recipe tomorrow.

urunner 0.1

Have at it. Bug reports welcome, patches even more so.

WordPress migration

Tuesday, January 27th, 2009

Drupal was a pain to update and in some ways to work with, so I threw WordPress on here and migrated the posts using this Drupal->Wordpress migration script. I guess there’ll be some edges to round off still, but it seems to have gone successfully. I’ll also need to do something about making it look nicer than the default theme.

Introducing Hermit

Friday, January 2nd, 2009

This is something I’ve been tossing around and occasionally working on for a while now – a decent to-do list/task manager usable at the command line. The key features for me were the ability to combine multiple separate sets of tasks into one and to have some of those be remote, accessed over the network.

Nobody seems to have made something like that before (perhaps my use-case is unique?), so I put this together and have been using it over the last couple of months. It’s reasonably simple to use – `hmt add` and `hmt list` being the main commands, with `depends` and `edit` doing the obvious things too.

The important aspect to me was remote task repositories. These are specified in the .hmt/config file, just by an entry of the form “[external]“. Tasks from that repository will be included in list output, and can be depended on. If you have write access to the repository they can be edited and resolved as well, just like local entries (it’s fully transparent). Repositories can be accessed via the local filesystem, over HTTP, or by (a very na├»ve) SSH transport. The SSH transport is mostly intended as a writer for remote repositories accessed by other means, but it supports read access as well.

Any repository can have a “writer” specified, either locally or in its own configuration, which specifies where writes to it should go. That lets non-writable HTTP repositories be edited in the usual way over SSH. They can also specify caching to avoid continual network traffic and be combined in more complex ways. Development is ongoing when I have time and an itch, but it’s almost fully usable for the single-user case now. I have it running on a few servers creating lists of administrative tasks to complete, and that works fine over the network too.

I also used git to maintain my code this time, to try it out again. It’s definitely much more usable than the last time I tried it. In-tree branching is a lot of fun (especially with KDE4′s Kate, which finally offers to reload all changed files at once). Directory tracking is still poor, and I had to take a few goes at getting something acceptable when I renamed one. I don’t know whether I’ll continue to use it or Bazaar in future, but it’s passable.

It’s also Python 3 compatible via `make 2to3`. Working on code that works both ways through that has been an interesting experience. For 2.6 or 3.0, you’ll have to export a valid PYTHONPATH or move lib/python to lib/pythonx.y.

The repository is available at for the moment. Very early stages, but have at it.