Sometimes you run programs in xterm windows that try and do you a favour, by setting the xterm title property. Potentially useful enough, but aggravatingly some of them don’t restore the previous title when they exit. If you’re using some scheme of your own to set meaningful window titles, this is annoying.
Here’s a shell one liner that you can use to grab the current title in an xterm. You could use this to write a wrapper script that gracefully launches any such rude application, and restores the rightful title property when it’s done
/usr/X11R6/bin/xprop -id $WINDOWID | perl -nle 'print $1 if /^WM_NAME.+= \"(.*)\"$/'
Ever wanted to combine multiple individual PDF files into a single PDF document? Say you were scanning a paper document, a page at a time, and wanted to collate the digital pages back into a single document. Or collect together a number of similar PDFs you’d generated
via ‘Print to PDF’, perhaps to send via email.
You can do this incredibly simply in Leopard, without resorting to any additional software. PDF is such a fundamental component of Mac OS X, you can script operations like this using a very simple Automator workflow.
Just build the following sequence of actions.
1. Files & Folders: - Get Selected Finder Items
2. PDFs: - Combine PDF Pages
3. Files & Folders: - Open Finder Items
Select all the individual pages in a Finder window, and then run the workflow. After a short wait, while the actions are run, a multi-page PDF will open in Preview. Choose ‘Save As’, to create a new file. Notice the optional Quartz Filter operations you can apply to the new document when you save.
Another kind of iteration you often want to do when constructing programs, is to count things. Quartz composer provides the counter patch, which increments a running total when one of it’s inputs switches from false to true. Similarly, it decrements the total whenever the signal to it’s other input changes from false to true.
By generating a regular true/false alternating value, and connecting this up to the increment line, you could generate a regular count. This composition demonstrates one way to do this. Using the
Patch Time
patch, a count of time in seconds is passed through a modulo 2 operator to generate a regular sequence of alternate 1s and 0s. This is connected up to the increment line of the counter, which then counts upward in integers.
The counter value is used to govern the stripe width of a vertical stripe pattern. As the patch runs, the stripe width increases every other second. This is a very simple display, but the bit generator and accumulator demonstrated are useful in a variety of ways. You can download a copy of this patch here .
Quartz composer is a visual programming tool from Apple that ships as part of the Developer tools with Mac OS X 10.4 or later. It presents a visual object-oriented programming metaphor around Quartz and Core Graphics that allows you to simply compose graphical effects by connecting inputs and outputs of different objects together, graphically.
You can use QC to build pipelines that respond to a variety of inputs, local or via peripheral interfaces to construct visualisers for a variety of source signals, such as MIDI, audio from the built in mic, video signals from an iSight camera, or even networked events from computers on your internet or LAN. It also can be used to procedurally generate graphics, which you can use to build fancy displays or screen savers. Some of the system screen savers that ship with OS X, like the ‘word of the day’ or the ‘rss visualiser’, are actually simple Quartz Composer scripts.
It’s an impressive tool, and ships with documentation and some examples of what you can do. You can achieve nice effects quite quickly, but there is still a learning curve to climb. As an example, a common thing you might want to do when constructing simple animating displays, is loop over a set of possible outcomes. Iterators are a common piece of the vocabulary of programming languages, but it took me a little while to figure out how to achieve this with the ‘box and string’ interface of this tool.
Here is a simplistic solution solution I came up with. Read the rest of this entry »
XCode has a nifty integrated debugger which is really a pretty wrapper around gdb . It lets you point and click, and drill down on things within the gui with ease, but still preserves access to the underlying raw gdb console and output. You can create breakpoints and watches, both literal and dynamic, step through your application as it runs, all the usual stuff.
I’m not the world’s greatest user of debuggers. I’m more likely to trace through things until they make sense using some combination of logging, print statements, paper and pencil, or my absolute favourite, just explaining your mystery problem out loud to a nearby third party, embarrassing yourself by spotting the obvious bug mid-flow. That last one sometimes even works with the dog. Sometimes though, you’re stumped, and you want to set some watchpoints, step through your program as it executes, or just generally prod things mid-run, and poke around under digital rocks.
Something I’ve been trying to practice recently is Test Driven Development . XCode 3 ships with support for the OCUnit testing framework built in. You can add a Testing target to your XCode project, and build up test case classes that use this framework, and the build tools know how to run these through the test harness. And so you progress, write a test for a feature, run the test harness, write code to pass the test harness, repeat. It’s a great way of not only catching certain classes of bug before they happen, but perhaps more interestingly imposing a more minimal design focus on your application as you build it; you’re automatically casting yourself more in the mind of a consumer of your application services, something I find really helps avoid over-design.
At some point though you are likely to run into some kind of hard to understand failure case within a unit test, and find yourself reaching for the debugger. And then finding that the debugger doesn’t work. This is because the runtime of your unit testing target is actually the separate test harness framework, and not your application target. The test harness is a regular application that’s dynamically loading your test classes and running them. In order to be able to use the IDE to debug your unit tests, you just need to do a little extra configuration within your XCode project, as follows.
It shows how infrequently I use it these days, but I yesterday found myself using a remote X client on my Macbook, and to put it bluntly, the X11.app as shipped with leopard is fucked. When I was working for IMDb, this would have scuppered my world. I can’t decide if I even need it enough now to make it worth trying to fix.
Of course I had to try! Installing the latest community developed packages seems to fix most of the immediate problems, giving a useable X11. And the new code base, and launchd integration bring real improvements over Tiger. Now quartz-wm is open source, X11 on the Macintosh can be synchronised with X.org. It would be even better if Apple folded some of these fixes into official updates.
I acquire new music at a relatively steady rate. I’ve been use my computer as a music library, storing my purchased music on a fileserver. Once I migrated to Macintosh, I started using iTunes to manage this process. It’s a useful solution, what small trouble I do have is usually related to my unusual configuration. I keep my music collection on an NFS filesystem, enough of a weird thing to do that I’m surprised iTunes doesn’t have more trouble with it.
A few years into this process I decided to get a portable audio player. An iPod was the obvious choice, despite the cost. Plug and go, lovely interface, Just Works™, all the usual. The 40GB model I went for was larger than my entire music library, compressed, to mp3 or increasingly to aac , with moderate settings. Synchonising is almost magically simple; set the iPod to sync ‘checked items’ and uncheck anything in iTunes you wish to exclude. I extolled the benefit of this approach to anyone who asked.
There approach will only scale so far. After several years of acquisition, the ‘checked’ set must exceed the 40GB capacity of the device. Luckily, by the time I reached it, Apple upgraded the iPod range, the new ‘classic’ guise, offering a potential 160GB storage . I toyed with one of these on display in a shop, but quickly gave it up unconvinced. I had misgivings about the new unit, foremost was the surprisingly sluggish interface.
I detest New Year’s Eve, and I’m not an enormous fan of the Gregorian Calendar , which seems to me to be one of those aggravatingly archaic measurement systems, which whilst possessing romance and historical pedigree in gross quantities, really don’t scale too well to the modern age. And don’t get me started on time-zones …
Database-nerd pedantry aside though, I do really like New Year resolutions. I like the idea of working at self-improvement, and consequently I always make a goodly set of targets for myself, mostly privately. They’re not always focused on tangible goals, and those that are I often fail to meet, but then, stretching oneself is sort of the point.
Probably the silliest scheme I’m going for in 2008 is to quit drinking alcohol. Not that I think I have a problem, as you’re traditionally obliged to add as a follow up to that statement. As a regular alcohol user though, I do think it will present an interesting challenge, and I suspect it will have a generally beneficial effect on my health, and also my bank balance. I’m in good company too, it seems like Richard Herring is joining me on my quest.
I’m going to leave myself the cop-out clause, of still allowing champagne. Firstly, it allows me to join in the toasts at significant social gatherings. Secondly, it lends an air of faux-class, as by champagne, I mean your actual champagne; none of your prosecco or cava, thanks very much. Thirdly, if I find myself regularly buying crates of champagne at bulk discount for home consumption, I’ll have good grounds to accuse myself of hiding a drink problem.
Another good thing about breaking in a new year, is that it encourages change. I’ve already indulged in some long-neglected home improvement work, and I’ve extensively rebuilt and replumbed this website to use the WordPress system for the blogging bits. The base URL has changed , and there’s now a wider variety of detailed feeds . I’ll endeavour to maintain all the old permalinks and feeds with redirects, and I’ve migrated all the old content across. There is bound to be breakage, so let me know if you spot anything.
Previously, I was using a publishing system which started out as the marvellously simple blosxom , which progressively grew less marvellous and more complex as I hurriedly hacked new features into it on demand, or whenever the mood caught me. Blosxom is ace, and if the idea of a blogging tool that is just a perl script that builds static content and uses text files within the filesystem instead of a database strikes you as intriguing, you should definitely give it a go.
Blosxom development seems to have stagnated for a long while, although there’s recently been more activity , and my slapdash customisations had grown crufty and brittle enough to make my publishing environment fragile, and irritating to change. And so, WordPress. This brings all sorts of new features I’ve been asked for, but too lazy/busy to add in the past (comments!), extensibility and an active development, and it’s based on the industry lowest-common-denominator combination of apache / PHP / mysql, so I can keep control of my own content, yet can easily move it to pretty much any cheap-ass hosting provider under the sun if needs be.
And as an added benefit, I expect I’ll be posting more frequently, at least until the novelty wears off.
Since I switched to using Macintosh predominately, I’ve tried a few different programs for editing text. I auditioned some of the available Macintosh native applications. The built in text editor, “TextEdit” is surprisingly useable, although it no longer offers much specific programming support. XCode has a capable editor, with IDE features for Macintosh application development, but it’s too slow and large to be more generally useful. The power editor on Macintosh always used to be “BBEdit” , but it’s expensive, and seemed complicated and old-fashioned. TextMate is very interesting, an attempt to bring together UNIX editing concepts with the OS X application frameworks, and I was nearly tempted to switch to it full time, but I eventually decided to stick with the editor I know best, GNU emacs .
It turns out that that’s not as straightforward a decision as it might seem. There’s a variety of different emacs implementations on offer. Apple ship a version of emacs 21 in /usr/bin , but it’s purely a terminal based application that has to run in an emulator window. This works well enough, but has restricted font rendering, and your editor session isn’t an application instance at the top level, being subprocess of the terminal application. You could compile a GUI emacs using the Apple X11 server, which improves the font handling, but still would be a sub-application process, and would introduce the usual klunky X11 clipboard integration . There are also a few ‘native’ Emacs application ports. Andrew Choi has ported both GNU Emacs and XEmacs to the Macintosh OS X carbon APIs, and there is something called “Emacs.app” which is an update of the NeXT Emacs port to a more modern emacs base.
I seem to have settled on using the Carbon emacs port, in a new variant that uses the ATSUI text rendering framework rather than QuickDraw . This seems to fix some of the very ugly font rendering behaviour I used to sometimes see with Carbon emacs. I suspect I am probably rather oversensitive to font rendering accuracy. I think this new engine is only available in the CVS tree for emacs, but this is quite simple to install on a Mac using MacPorts .
sudo port install emacs-devel +atsui
A remaining niggle is the use of emacs in server mode. Emacs is rather a heavyweight application, taking some seconds to load, and it carries a lot of state. Ideally you want to perform all of your editing in a single emacs session, rather than starting a new editor anew each time. Emacs has a client/server mode to allow you to do just this. Simply add
(server-start)
to your .emacs file to start the server, and use the emacsclient program as your editing tool. This contacts the running server and creates a new buffer for the invoked editing context. Setting your environment variables for EDITOR and VISUAL means that shell commands will use the emacs server as your default editor.
The niggle is that you then have to switch window context to edit. And as autoraise and raise-window do not seem to have any effect on Carbon Emacs, you have to manually find the emacs window for the server that is waiting for your edits, probably buried under a pile of windows. I’ve managed to go some way to fixing this problem with an unholy marriage of elisp and AppleScript.
The AppleScript
Tell application "Emacs" to activate
will raise the running emacs frame and switch focus to it. There is a command line program provided with OS X, osascript that can run AppleScript programs from script files, or run one-liners via the -e argument. It is therefore possible to add some elisp to the emacs initialisation scripts to automatically run the AppleScript snippet.
(defun my-server-visit-hook()
(interactive)
(shell-command
"osascript -e 'tell application
\"Emacs\" to activate'"))
(add-hook 'server-visit-hook 'my-server-visit-hook)
Every time a server buffer is created, this hook will be called, and emacs will raise itself to the front of the window stack, steal focus and prompt for input, which seems to be mostly what I’d want. I have yet to devise a manner of returning to the calling window context after editing, which will probably be a less trivial hack.
Apple have been providing the ability to securely encrypt your home directory for the last few versions of OS X. The cute name they have for this is FileVault . It’s largely a transparent business, and perhaps useful to have if your data might be found lying around somewhere, so I tend to enable it for portables.
It’s not entirely invisible. During use, your home directory changes to a spiffy modified icon. Logging in, and working with very large files seems to be slightly slower, and it prompts you to reclaim space on logout, which can take quite a while if you’ve recently re-organised a lot of data. And there’s a few more obscure differences that might show up. I was recently bitten by one of these, and perhaps it’s a testament to how seamlessly FileVault is slotted into the system in that it took me a little while to figure out what was going on.
I’d been playing around with some toy code for some co-operating daemons, and I was tweaking a section that might open some files read-write, to check that they would work with minimal access permissions. On a mac I tend to do all my development work inside my home directory, much like I do everything else. So I changed the ownership of my exectuable to a dummy user, enabled the set-user-id bit, locked down my data file’s permissions, and ran the tests. I wasn’t particularly suprised when it failed with access errors. First pass, my code, bound to be wrong.
I double checked the permissions and ownership, files owner only, process owned by the right uid, setuid bit on. I read the man pages for chmod and chown again. Still no joy. I fished out a copy of APUE and wrote the simplest possible test case. It still wouldn’t work. Whatever sequence of library or system calls I tried, the effective user id of the subsequent process was always me.
After a while I figured it out. When you enable FileVault for a user account, your home directory has a binary file called yourloginname .sparseimage within it. This is your FileVault home directory, in the form of a sparse encrypted disk image. When you login to your account, this image file is transparently mounted under $HOME, using the OS X disk image framework. When you logout, it’s unmounted again. You can manually mount it from a shell using the hdiutil tool like this
hdiutil -stdinpass -mountpoint /Users/foo /Users/foo/foo.sparseimage
You’ll get a prompt for the image password, which will be the same as the UNIX account password. You need to type the null at the end of the password, which you can do with C-@ , before you hit return. If you type mount you’ll see the disk image listed in the mount list. You will also notice the default options for disk image attachments is to mount them with the nosuid attribute. This causes OS X to silently disregard any set-user-id attributes of files within the filesystem. This makes a lot of sense as a security measure, and is commnly used for filesystems on removable media. You don’t want foreign filesystems introducing set-user-id binaries into your local filesystem on an ad-hoc basis as they are mounted.
Your own securely encrypted home directory doesn’t really represent a similar security risk, especially if you’re already the main administration account for your mac, and so the precaution seems less useful here. I wondered if it was a deliberate policy decision, or a side effect of the disk image framework. I’m not sure if you can mount disk images without nosuid at all.
When manually mounting filesystems, nosuid is an optional property supplied to the mount command. It seems like it ought to be possible therefore to mount disk images without the nosuid attribute being passed through to mount , but I haven’t yet managed to find a way to influence the mount options passed from hdiutil . Nor have I found where the magical FileVault attach happens, or if there is any way to influence it’s settings. In practice, it doesn’t really matter much, as set-user-id binaries have a very limited use, and probably shouldn’t be encouraged to proliferate.