therning.org/ magnus

A little while ago I wanted to launch an OGG file attached to an email. Since I read email in Mutt and it does such an excellent job of delegating unknown MIME types to external applications I simply pressed v (to see the attachments), selected the OGG attachment and pressed enter. Realplayer launched! Imagine my surprise.

After purging Realplayer from my system I had an idea. Mutt uses mailcap to determine how to deal with MIME types it can’t display, but since I’m using GNOME and it has a different system to deal with MIME types I frequently am surprised when viewing attachments in Mutt. Isn’t there some way of combining the two? Well, I frequently use gnome-open to launch viewers from the command line. But it forks off a new process for the viewer so it can’t be used in mailcapⁱ. I spent some time looking into the inner workings of gnome-open and it might be possible to hack it to add a command line option to make it wait for the viewer to exit. However my quick test using Python suggests that it’d require changes in the underlying librariesⁱⁱ.

From what I learned looking through the implementation of gnome-open I hacked together the following short Python script:

#! /usr/bin/env python

import gnomevfs
import os
import sys

mime_type = gnomevfs.get_mime_type(sys.argv[1])
mime_app = gnomevfs.mime_get_default_application(mime_type)
application = os.popen('whereis %s' % mime_app[2]).readline().split(' ')[1]

os.execl(application, application, sys.argv[1])

Then I added a line to the top of ~/.mailcap:

application/*; ${HOME}/bin/gnopen '%s'; test=test -n "$DISPLAY"

Works like a charm, but of course suggestions/improvement are welcome!

1. It seems Mutt removes the temporary file as soon as the viewer returns, so if gnome-open forks and exits Mutt will delete the file before the actual viewer gets to load it. Bugger.[back]
2. I traced it down to a call to g_spawn_async that should be changed to g_spawn_sync, but that’s deep down in the underbelly of GNOME-VFS.[back]