Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Wednesday, September 24, 2008

AppleScript, for once

AppleScript isn’t something I write much about, in fact this is the first post I’ve ever created on the topic. But AppleScript, like the Services menu and Automator, provides that most useful of usability enhancements: the ability to use multiple applications together without fulfilling the marketing requirements of having to look at them all.

As an example, a folder action script might let me combine the Finder with any other application, such as, choosing completely at random, Sophos Anti-Virus:

on adding folder items to this_folder after receiving these_items

  set theScript to "/usr/bin/sweep -nc"

  repeat with i from 1 to number of items in these_items

    set thePath to POSIX path of item i of these_items

    set theScript to theScript & space & thePath

  end repeat

  set theScript to theScript & space & "--quarantine:mode=000"

  do shell script theScript

end adding folder items to

that script then scans any file which appears in a particular folder and locks it if it contains a virus (up to a point). But that’s not really the point, the point is that I haven’t actually had to use any of the target apps in order to get this combined functionality. It’s like I was able to summon the Megazord without having to actually talk to the individual Power Rangers. Erm, or something. And that, really, is how a computer should work; I didn’t buy OmniFocus so that I could look at its icon, or a splash screen, I bought it because it can manage my lists of things to do. And I got iCal in order to manage events in time. If I have things to do at specific times, then I ought to be able to combine the two, and the computer can do the work involved. After all, that is why I bought the computer.

posted by Graham Lee at 21:01  

Monday, June 16, 2008

Local KDC on Leopard

via Nigel Kersten, a great description of the operation of Leopard’s built-in local KDC. I think the most exciting thing about the local KDC is the Bonjour support; could we see simple cross-system trust in the near future? Could there be someone in the world who can actually make Kerberos simple?

posted by Graham Lee at 21:28  

Saturday, February 16, 2008

Well, you could have told me

When looking through some of the configuration options on my laptop (well, it’s either that or go to the pub and socialise with humans) I came across something I couldn’t account — pardon the pun — for. A new user account on the system, short name messagebus, full name "Message Bus" user id 506. Now messagebus looks like the name of a system daemon user, but that full name looks like some clueless skiddie made a mistake creating the user account, especially as the uid is that of a regular user. That’s the kind of mistake no self-respecting installer would make.

So, what had this phantom user done? Well, thankfully, nothing. Neither the shell nor home directory was real, and wtmp/utmp showed no activity. Neither did the ssh logs – but in looking for them I realised that I don’t actually use ssh on the box, so turned it off.

Anyway, it turned out to be an innocuous issue – the MacPorts installer for dbus creates this bogus user, which I’ve since deleted. This Apple forums discussion explains more.

posted by Graham Lee at 00:41  

Saturday, May 12, 2007

A bit of backup script

Good news – there’s a handy tool in OS X called wait4path which can help when writing timed scripts to backup to removable media.

Bad news – it [at least in Tiger….] works slightly esoterically – if a path is already present, it will still wait for another mount kevent before exiting. It should therefore be used in a script like this:


#!/bin/sh

if [ ! -d /Volumes/Backups ]; then
echo "waiting for backup volume..."
/bin/wait4path /Volumes/Backups
fi

# do some backups

Note, however, that if you do this in a crontab job it could potentially wait for a very long time, so you should wrap all that with a /var/run style semaphore.

posted by Graham Lee at 12:48  

Thursday, March 15, 2007

Mail::Box++

When most perl developers (I believe there still are one or two in existence) talk of the "cool one-liner" that they wrote, what they actually mean is that they grabbed a crapload of packages from CPAN, invoked a few use directives and then, finally, could write one line of their own code which happens to invoke a few hundred lines of someone else’s code, which they have neither read nor tested.

Modulo testing, my short script (below) to convert mbox mailboxes to maildirs is exactly like that. While it has three lines of meat, these call upon the (from what I can tell, fantastic) Mail::Box module to do the heavy lifting. That package itself is less svelte, with 775 lines of perl. Which is the interface to a C bundle, which is (single-arch) 92k. But never mind, I still wrote a three-liner ;-)

#!/usr/bin/perl -w

use strict;

use Mail::Box::Manager;

@ARGV = ("~/mail", "~/Maildir") unless @ARGV;


# open the existing (mbox) folders
my $mgr = new Mail::Box::Manager;
my ($srcPath, $dstPath) = @ARGV;
# expand tildes and stuff
$srcPath = glob $srcPath;
$dstPath = glob $dstPath;

opendir MBOXDIR, $srcPath or die "couldn't open source path: $!";

foreach my $file (grep !/^./, readdir MBOXDIR)
{
my $mbox = $mgr->open(folder => "$srcPath/$file",
folderdir => "$srcPath");
# open a maildir to store the result
my $maildir = $mgr->open(folder => "$dstPath/$file",
type => "Mail::Box::Maildir",
access => 'rw',
folderdir => "$dstPath",
create => 1);

$mgr->copyMessage($maildir, $mbox->messages);
}
posted by Graham Lee at 17:32  

Powered by WordPress