The Fugue

For my musical notation needs, I use LilyPond.

LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.

On Leopard, LilyPond is severely broken. The IDE will "start", but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I'll describe them as one and the same.

First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it's for G3, G4, G5 Macs).

lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don't want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they're taking up disk space anyway let's help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here's the code:

#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"

Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:

alias lilypond='ly lilypond'

The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.

Once upon a time I was on a quest to get Ogg Vorbis working on a Mac. I tried the QuickTime Components project and it worked for awhile. Then it broke with QuickTime 7. Truth be known, it never worked all that great before, though it did decode the music. Then I found VLC and never looked back.

Today I learned that somewhere in the interim Xiph.org filled the gap. Now you can download XiphQT, stick XiphQT.component in /Library/Components, and you're off and running. This is precisely how the issue should have been addressed in the first place, and I'm glad it finally was, whenever it was. I'm also happy to have been ignorant of the fact for so long, since I despise iTunes for other reasons, and this tells me I've lived without regular iTunes abuse for a long hapy time.

In the spirit of release early, rewrite often, I have released Crème Rappel version 2. Version 1 was a shell script that combined Growl and at. Then Apple released 10.5.2 not half a week later and broke at altogether. Sick of fighting with launchd and other Apple superiority complexes, I set about to nurture my own superiority complex and rewrite Crème Rappel to be completely independent of at.

Of course, that's getting too heavy for a shell script, so I moved to Ruby. One thing I didn't want was to require a daemon to be running. Daemons can fail or forget to start up, and that means I couldn't really truly trust the tool. The recent at debacle is just another case in point. So, instead I wrote Crème to fork a process that sleeps until the moment of truth, then fires off the reminder. It turns out the obvious function for the job, sleep(), is a poor choice here. In fact, every timer I tried had the same problem, including one I thought would not: setitimer(). When you suspend the laptop, it appears you also suspend time. If you don't believe me, try this simple experiment:

date; sleep 30; date

Put the laptop to sleep during the sleep for a substantial time, then notice that when you resume you still have to wait for the full 30 seconds to tick by even though it has actually been a minute plus since you issued the command. So I sleep for one second intervals instead, checking the time every time.

This is not just a backpedaling rewrite, though. It also adds more flexible and easy-to-type timespecs, and a spiffy website. If you give it a try and it doesn't work, or you struggle with the documentation, please do drop me a line so I can fix it. I want it to be worth every bit of bandwidth that you paid for it.

OS X's Termina.app is the terminal I've been using since I switched to Leopard, because it has tabs now and it's beautiful. Oh, and iTerm gave me too much grief with odd, illogical and unpredictable bugs.

One of the drawbacks to Terminal.app is that it's broken. This is what Aptitude looks like with TERM=xterm (I think this is the default):

This is what it should look like:

How to get from there to here? The short answer is to choose dtterm as your terminal emulation (in Preferences, on the Advanced tab).

The long answer is that the problem here is that xterm supports this capability called back-color-erase (bce). If you tell programs that you are an xterm (with TERM=xterm), they will assume you support bce. The same goes for rxvt and xterm-color and even vt100 (even though that one doesn't seem to support color). bce isn't the only problem, either. There's also redraw problems that are difficult to show with a screenshot.

Setting TERM=dtterm seems to get rid of at least the major breakage. It would seem that the actual capabilities of Terminal.app are closest to dtterm, or at least closer to dtterm than to xterm or rxvt. It solves all the issues I've been having with aptitude, mutt, and screen locally and on remote linux boxes. But there's a caveat—not all remote systems will have the dtterm entry in their terminfo databases. Ubuntu 7.10 didn't by default, for example. The package you want on Debian-based systems (like Ubuntu) is ncurses-term.

Alternatively, you can install it in your home directory. To do this, on OS X type

infocmp > /tmp/dtterm
scp /tmp/dtterm username@example.com:/tmp
ssh example.com tic /tmp/dtterm

tic (terminfo compiler) will create a terminfo database entry in ~/.terminfo/d/dtterm, and you should be good to go.

I discovered a very strange bug today with OS X's Bourne shell. If you have OS X, give this a try:

/bin/sh -c 'echo -n bug'

This is what you should see:

$ /bin/sh -c 'echo -n bug'
bug$

This is what I see:

$ /bin/sh -c 'echo -n bug'
-n bug
$

In other words, it's ignoring the -n option. It works fine in bash, it's only sh that's broken. It gets better though. If you're using iTerm instead of Terminal.app, it works fine. I have combed through the environment, the locale settings, the terminal emulation, and I can't account for it. I've tried ssh from a linux box which behaves the same as Terminal.app (broken). Who knows what black magic iTerm is invoking.

So I replaced my bash and sh with the ones from MacPorts:

sudo port install bash
sudo mv /bin/bash /bin/bash.old
sudo mv /bin/sh /bin/sh.old
sudo ln /opt/local/bin/bash /bin/bash
sudo ln /opt/local/bin/bash /bin/sh

While you're at it, feel free to

sudo port install coreutils +default_names

Problem solved. Very odd, though. abcde uses echo -n heavily, which breaks in all sorts of ugly ways before this fix. This patch causes abcde to use /bin/bash instead of /bin/sh:

Index: abcde-2.3.3/abcde
===================================================================
--- abcde-2.3.3.orig/abcde  2007-12-07 18:46:36.000000000 -0700
+++ abcde-2.3.3/abcde       2007-12-07 20:57:17.000000000 -0700
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# Copyright (c) 1998-2001 Robert Woodcock <rcw@debian.org>
# Copyright (c) 2003-2005 Jesus Climent <jesus.climent@hispalinux.es>
# This code is hereby licensed for public consumption under either the
Index: abcde-2.3.3/cddb-tool
===================================================================
--- abcde-2.3.3.orig/cddb-tool      2007-12-07 20:56:49.000000000 -0700
+++ abcde-2.3.3/cddb-tool   2007-12-07 20:57:19.000000000 -0700
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

# Copyright (C) 1999 Nathaniel Smith <njs@uclink4.berkeley.edu>
# Copyright (C) 1999, 2000, 2001 Robert Woodcock <rcw@debian.org>

Speaking of abcde, here's a patch to get rid of an unrelated bug in 2.3.3:

Index: abcde-2.3.3/abcde
===================================================================
--- abcde-2.3.3.orig/abcde  2005-08-25 16:43:27.000000000 -0600
+++ abcde-2.3.3/abcde   2007-12-07 18:46:36.000000000 -0700
@@ -1946,7 +1946,7 @@
                        FILEPATH=$(find "$FILEPATH" | grep "/$REALTRACKNUM ");
                        # If the file exists, copy it
                        if [ -e "$FILEPATH" ] ; then
-               nice $READNICE $CDROMREADER "$FILEPATH" "$FILEARG" $REDIR
+               nice $READNICE $CDROMREADER "$FILEPATH" "$FILEARG"
                        else
                                false
                        fi ;;

Finally I have abcde at my fingertips again. There's no replacement for abcde when it comes to ripping CDs.

To build ncmpc 0.11.1 on OS X, you need to allow nested functions, like this:

CFLAGS=-fnested-functions ./configure
make

ncmpc is my preferred mpd client. mpd is my preferred "juke box", but Von and I intend to change that over Christmas break.

One of the more drool-inducing features of Leopard (for geeks, anyway) is Spaces, Apple's virtual desktop implementation. I'm a big virtual desktop fan, and I'm glad to see it working its way into the mainstream. And all things considered, Spaces is a decent (and beautiful) implementation.

But there are some bugs. I hope that we will see them worked out. Some of the bugs are in Spaces itself, some are probably with 3rd party applications. The most notable, and annoying, problem is buggy application switching. When you cmd-tab to switch applications, you are taken to the space with that application. This is good, but it must have given the Apple developers heartburn because in some ways it flies in the face of the "Apple Way", which thinks of an application as a whole not as independent windows. That's why the menu bar is at the top, and it's behind the design of the dock. But what happens when there's a Terminal window on this Space, and on that Space? The natural thing should be, switch to the terminal window in this Space. If that's not what the user wanted, well you can't be expected to read minds. But when I cmd-tab to Terminal, I am always taken to what Leopard apparently thinks is the master Terminal Space, regardless of whether I have a Terminal window in this space, which Terminal window I last used, etc. Bad news. As a workaround, I just put Terminal on all spaces and thank my lucky stars it has tabs now. This affects most multi-window applications to some degree, but it's most annoying with Terminal and Adium.

On a related note, I'd expect cmd-` to switch between windows of the same app on different Spaces, but it only switches between windows on the current space.

Some applications, especially Firefox and to a lesser extent Thunderbird, have focus bugs that may be related to spaces. Sometimes when I switch to Firefox (with cmd-tab), the window is not in focus and is not brought to the foreground. The menu bar reflects that I'm in Firefox, and I may have moved spaces to get there, but it's in the background. I have to switch to it with cmd-` (or, horror of horrors, with the mouse). I imagine this is the sort of thing that Apple and/or Mozilla will hammer out soon. There are other Firefox irritations but they're for another post—if they haven't been fixed by then.

So far, nothing too surprising. Virtual desktops is hard to get perfect, and various Linux window managers have been floundering for years or even decades. Overall, I'd say they're off to a smashing start. I have two other more minor irritations. First, I'd like the current application to stay the current application when I switch spaces with the keyboard, instead of switching to the topmost application in the new space. This is because I often want to choose an application (by cmd-tabbing to it), then navigate to another space where I want to open a new window (e.g. Terminal). This is a design decision, of course, and one that people tend to fall on either side with about 50% probability. The second is keybindings. I'd like to switch spaces with cmd-ctrl-hjkl (Vim keybindings). Maybe we'll find a way. I'd also like to have more keyboard operations, especially "move me and this window to the {left,right,up,down} space".

I recently had need to put a .bst file in my LaTeX search path. This turned out to be difficult to search for. I found a lot of pages and style files telling users to put such and such file in their LaTeX search path. I began to wonder if I was the only LaTeX user on earth who had no idea what the LaTeX search path was.

With some effort I found that the global path's root is usually something like /usr/share/texmf. I'm not interested in putting it in the global path though. We have home directories for a reason here.

Finally I found the answer, with some creative googling. The answer depends on your distribution/OS. Apparently on Debian it's ~/.texmf-config (untested). The MacTeX distribution (which I have installed) looks in ~/Library/texmf. The macports build (don't ask) looks in ~/texmf, which I learned only by trial and error. My guess is that latter answer is the answer if you build by yourself, and so might be a good initial guess no matter what the distribution.

So, I did this:

mkdir -p ~/Library/texmf/bibtex/bst
ln -s ~/Library/texmf ~/texmf
mv acm-annotated.bst ~/texmf/bibtex/bst

The OS X Leopard Calculator has one very nice change. A picture is worth a thousand words and I'll let this one speak for itself:

Once upon a time, bash (or some other shell) introduced color in the shell prompt. The syntax was funky and all but illegible, so manpages and HOWTOs were written. The technical elite (i.e. high school kids and sysadmins with nothing better to do than configure their bash prompts) rejoiced.

Once upon a more recent time, I crafted this bash prompt:

PS1='$(r=$?; [ 0 == $r ] || echo "\[\e[33m\]$r\[\e[0m\] ")\u@\h:\w\n\[\e[32m\]\$\[\e[0m\] '

Actually, its history is more of an evolution than a crafting, but nonetheless I like it.

Then, out of the blue, someone broke bash. The \[ and \] non-printing character delimiters stopped working (or stopped working properly). Their purpose is to tell bash that the stuff inside is non-printing so don't count it when you're counting the number of characters in the prompt. This is vital for proper wrapping and tab completion in the presence of color escape sequences. I don't know who broke it or why, but removing \[ and \] seemed to fix the symptom.

Fast forward far too long, and someone fixed the problem. Once again you needed \[ and \].

Fast forward again, and it's broken. Or maybe we're just going around in circles on which version of bash is being used in various distributions and OS's. In this case, Ubuntu is still (or again) broken and OS X is broken in a different way. They're both running 3.2.x. The bug is probably the same and the manifestation is simply different.

The current manifestation of this bug is that neither with nor without the delimiters works. I'm forced to go back to a noncolored prompt, and I'm not happy about it. This bug has been around for at least a year. I've reported it several times to various distros. Why is it not yet fixed? If they fixed it today, we'd still be battling the bug for years to come because of the many distros and OS's that have assumed buggy versions of bash.