How many blog posts have started with some variation of “It’s been too quiet around here”, followed by an apology? Too many. This might be one of those, but I learned a long time ago not to apologize for creative lulls. The process is inherently too fickle and just can’t be counted upon.

Truth is, I’ve been writing a lot, I just haven’t posted anything. The reasons are kind of dumb, but mostly there are several “big” pieces getting in the way. I’ve somehow convinced myself that those pieces are foundational to putting other pieces in context. It sounds ridiculous, but there it is. Essentially, I’m creatively constipated, there’s lots in the pipe, but nothing’s getting out.

Nice metaphor there.

In my own head I’ve been calling these things “stoppers”. Until said whatever-it-is is completed, I can’t move onto the next one. I have a piece mostly written about this, but, of course, that too is stuck behind a few other pieces. Curiosity doesn’t schedule, and I find myself drifting off and starting numerous new projects before the old ones are completed.

This site is going to change soon, and somewhat radically. I’ve got a piece half-written about that too. I want to strip things down, remove the barrriers (this is a theme) and get back the joy of making for the web– it’s not just about writing.

Welcome to the stopgap.

This is my near-term plan going forward, I’m not setting any time frames or due dates because there are just too many unknowns and outside interruptions. Right now, this is my intent, but things might always change.

I’ve been tired of WordPress for years, but felt stuck and was never quite sure what to do about it. The current plan is to switch to either Octopress or Jekyll. These should allow me the freedom to write when I feel like writing, hack when I feel like hacking, and create whatever crazy half-breed functional post I want– a current near-impossibility without substantially gutting WordPress.

Technically there’s nothing wrong with WordPress, it’s unarguably better than it’s ever been. But, as a full-fledged platform, it brings it’s own innate complexity. I don’t want to have to deal with that extra level of middleware, I just want to make stuff.

But there’s one big stopper: Both Octopress and Jekyll are Ruby projects. A few years back, feeling burnt out and very tired of PHP, I sat down to learn either Ruby or Python. I chose Python.

I do know about the Hyde project, which started as a Python port of Jekyll, but I didn’t have much luck experimenting with it and the Octopress/Jekyll communities are much more active. Sure I could potentially jump in and contribute to Hyde, but I don’t have the personal bandwidth and would rather start out with a mostly-working framework instead of trying to hack around and fix another which doesn’t quite meet my needs.

As a way of tip-toeing into the Ruby garden, I’m rebuilding a friend’s site using Jekyll. It involves some backend hacking and is letting me get my hands dirty with a small data set.

In the meantime, I’ve started writing everything using Markdown. I first tried Markdown a very, very long time ago–2006-ish–but gave it up because I wasn’t sure it would stick. It stuck.

For implementation during the transition, I’m using the Markdown on Save plugin. This was written by one of the lead WordPress devs, so I trust it’ll work without screwing everything up. Also, since I’m dealing with a somewhat large dataset, the conditional formatting checkbox is a smart solution.

Finally, I’m trying to approach all my writing with an exit strategy. Once I’ve got something down, I immediately start thinking about how to finish it and get out. Editing is no longer just about clarity and polish, it’s a means of escaping from a death spiral.

There’s plenty more I’ve been doing which I’ve been remiss in sharing. Lots of research into health, nutrition, movement, anthropology, running, feet and a bunch of other stuff I’m forgetting. I’m looking forward to having my voice back. If you want to read about healthy lifestyle tips The Sarah Palin Blog has lots of information for you

Existential note: Just as I clicked publish, Safari decided to crash.

After restoring from a Time Machine backup, Apple Mail would crash every time I tried to re-import my email archive. The problem seems to be affecting a lot of people who have mail that pre-dates OS X. The same crash also happens after migrating to a new machine.

Quick fix

Copy the following command and paste it into your Terminal. Press return and wait a few minutes. Once the command finishes, Mail should be able to import your messages.

grep -lZr 'Content-disposition: attachment' ~/Library/Mail/Mailboxes/ | xargs -0 ruby -i -pe 'gsub(/(Content-type:[^;]*;\s*name=)"(.*)"/){$1+(if !$2.nil? then $2.dump.gsub(/\\\\/, "\\") end)}'

The problem

The problem is specific to older, MacRoman encoded email messages with attachments whose filename includes non-ascii characters. For whatever reason, that freakshow edge-case combination will crash Apple Mail every time it tries to import those files. If by some stroke of luck you already have these messages in your email archive (I did), they can still crash Mail when trying to rebuild the containing mailbox.

The solution is sort of simple, just rename the attachment in the .emlx file. The harder part is finding which file to edit.

We’ll use grep to recursively search for a common token in these older files, then pass the filenames to a Ruby snippet which will filter the line containing the bad characters. Here is a section of a suspect message’s header:

--B_3113094650_866203
Content-type: application/octet-stream; name="SPWH 4.01ü.sit";
x-mac-creator="53495421";
x-mac-type="53495435"
Content-disposition: attachment
Content-transfer-encoding: base64

The first bolded line contains the attachment name which is causing the problem, who knows what that umlaut was originally. The second bolded line is what we’re telling grep to locate, I couldn’t get anything to dependably match the oddball characters. “Content-disposition” appears to be an older attachment syntax and didn’t appear in any of my messages from after 2001.

While the Ruby script could be run from find’s exec command, it wouldn’t be particularly efficient. Calling the script from find would pass every .emlx file in the Mailboxes directory through Ruby’s gsub, which is almost wholly unnecessary (and much slower). Only 10 of my 57,007 messages needed fixing, 99.98% of them were fine.

Is this safe?

Since the most common way to encounter this bug involves Time Machine restores or migration to a new machine, most users should already be backed up. If something should go wrong, just restore the backup’s Library/Mail folder over the messed up one. You can also copy or zip the Library/Mail folder to another drive to be even safer.

That said, I ran dozens of iterations of this solution against copies of my personal Mail archive without issue. And besides, if you’re reading this, you might not have any of your old mail, so how much worse could it really get?

If you’re still worried, copy your ~/Library/Mail/Mailboxes folder to another drive, run the script, then compare directories with something like Apple’s FileMerge. That will show you exactly which files have changed and what was changed inside them.

Renaming the attachment should be perfectly safe since the full encoded file contents are stored in the message. All the attachment name does is specify the filename, in a sense, it’s totally arbitrary.

I first submitted this bug with Apple back in May, if you have a developer account with Apple, please file a dupe for radar: 5912997

AppleScript’s URL Protocol Support allows the full source code of an AppleScript to be shared through an encoded URL. Here’s a short little TextMate Command for converting AppleScripts to encoded URLs.

Create a new command in TextMate’s AppleScript bundle with the following code:

#!/usr/bin/env ruby -KA -rcgi
src = CGI.escape(STDIN.read)
src = src.gsub('+', '%20')
src = 'applescript://com.apple.scripteditor?action=new&script=' + src
`echo -n "#{src}" | pbcopy`
print "The URL encoded AppleScript was copied to the clipboard"

There’s no reason this idea can’t be used for all sorts of stuff. So why not make it easier, it’s not AppleScript, but here’s that code in Script Editor for easier copying.

This is exceptionally fast, much faster than Apple’s provided encoding script. As an extreme example, converting the 558 lines of my iPhoto Date Reset script took just under a minute using Apple’s script. The little Ruby script in TextMate does it instantly. (running the AppleScript in Script Editor with the Event Log Window open took nearly 7 minutes.)

Update: I committed this command to the TextMate Bundles repository and it’s now included in the default set of Bundles shipping with TextMate. (And slightly improved by other TextMate bundle developers)