opendiff is a command line app for merging text files. It is installed when you install the Xcode Developer Tools on Mac OS X, and calls FileMerge.app. By default, opendiff does not wait for FileMerge.app to finish before exiting. This makes it hard to integrate opendiff with other Unix tools. After some searching, I found a solution.

In particular, opendiff will wait if the output is piped somewhere. I handle this by making a new shell script I call opendiff-w with the following code in it:

#! /bin/zsh
`/usr/bin/opendiff $@`

Then you can use opendiff-w just as you would opendiff, but it will wait until you quit FileMerge.app before continuing. It would be better still if FileMerge had a way to know when the diff was done without having to actually quit the app. Any suggestions?

I've often searched for a replacement for the standard icons that come with Apache. The default icons date back to Mosaic for X, and have been included in the NCSA httpd and Apache server distributions. These continue to be distributed with even the latest versions of Apache. I haven't found any publicly available replacements for these icons, so I decided to build my own.

I didn't reinvent the world here, I just modernized the standard set. The task of creating a whole new representational logic was too great a task for my purposes. Furthermore, the prevalence of these icons makes them easily understood. All icons maintain their original sizes, so they can be used as a drop in replacement.

On OS X, the standard installation location is /usr/share/httpd/icons. This directory is referenced by a global directive in the httpd.conf file. This includes an alias for /icons/ that is resolved for every domain being served. On OS X, this directory is owned by the system (root) with the group ownership belonging to wheel. It is best to follow the same permission model when replacing these files.

I received an iPod for Christmas -- I've admittedly been resisting this convenient technology because I am not satisfied with the audio quality of MP3s, even at the higher bitrates. I've revisited this issue since receiving my gift, however, and I'm mightily impressed with AAC at 256kbps: I've done listening tests of AAC against uncompressed audio with strings, voice, symphonic, and amplified music, and am sold on 256kbps AAC. It requires nice components for me to discern the difference from the original, and I sure can't on the little iPod.

I began converting my CD collection to AAC, but quickly became dissatisfied with Apple's tools to do this, either through iTunes or via Max. Neither does track normalization for a large collection, and Max's rips often produce white noise output for me.

Having used and trusted cdparanoia and cdrdao to obtain high quality rips for years now, I wrote a perl script based on these tools to rip a CD, grab the CDDB information, normalize the tracks, convert everything to a specified codec (AAC, ALAC, flac, mp3, etc.), and add the CDDB information to the resulting files. The script also does the correct UTF-8 conversion for non-English scripts. (I have an extensive Arabic collection from Beirut -- it's pretty neat to have the correct Arabic script appear in iTunes). To use this script, you'll have to download and build your own executables of the following tools (you must know how to type ./configure; make; make install):

• cdrdao (also via Fink)
• cdparanoia
• cuetools
• normalize (also via Fink)
• afconvert -- this is part of Apple's Xcode developer tools
• mp4tags -- part of mpeg4ip, which itself requires SDL)
• flac, lame, etc. (if desired)

I've written this script for my own needs, but it's easy to modify to incorporate other formats. To use, save the text to a file named cd2codec, do chmod a+x cd2codec, get/build the required tools, and type cd2codec --help for usage instructions. If you wish to add foreign language scripts to your mp4tags, then also grab a copy of my transliterate perl script, too, which provides the octal UTF-8 transliteration of Arabic and Greek. Cyrillic, Hebrew, and others are possible, too, but not implemented.

[robg adds: I haven't tested this one...]

I wrote this perl script which transliterates ASCII into UTF-8 colloquial and classical Arabic, Greek, and (at some point in the future) Cyrillic, Hebrew, and other scripts. Input: ASCII. Output: UTF-8 and octal representation of UTF-8.

I've used this to input foreign language titles into my iTunes world music collection. Once you've generated the octal UTF-8, this can be done by hand:


The iTunes song title of the AAC file 'ajmal mnw9aat al-jaaz 01.m4a will appear as 9rabiyuN 'anaa (عرَبِيٌ أَنَا). Or enter these codes into a cdrdao TOC file, and use my cd2codec script with the command cd2codec --utf8 to accomplish this automatically. I've written this script for my own needs, but it's easy to modify to incorporate other formats. To use, save the text to the file transliterate, do chmod a+x transliterate, get/build the required tools, and type transliterate --help for usage instructions.

Arabic transliteration is simply a colloquial Arabic front-end for Otakar Smrz's excellent ArabTeX perl script; you'll need to download and install Encode and Encode::Arabic from CPAN. I've also implemented a simple Greek transliteration engine (no accents or breathings) that runs without any additions. I've left placeholders for Cyrillic and Hebrew extensions, but these are not implemented.

[robg adds: I haven't tested this one.]

While messing around trying to share my iTunes library between two user accounts on the same iMac, I accidentally introduced a syntax error into my /etc/sudoers file. The big problem here is you need to invoke sudo to edit the sudoers file; I use pico, but visudo is recommended on this site.

So, to recover from this, I had to enable my root account using NetInfo in Applications » Utilities. Log in as root and edit /etc/sudoers, then once it's fixed and working, disable the root account again.

[robg adds: There's a good reason visudo is the recommended way to edit your sudoers file, and this hint is a perfect demonstration of why: because visudo includes a basic check for syntax errors, as explained in the man page:

visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors.

So you really should use visudo if you're going to edit the sudoers file. If you don't, however, and introduce errors, you'll need this hint to fix the problems.]

This may seem like an obvious hint, but I have been caught out by it a couple of times. When installing software using Fink or DarwinPorts (aka MacPorts), make sure you have the latest version of Apple's Developer Tools (Xcode) installed (free registration required to download).

Developer Tools is ignored by Software Update -- and using an old version tends to cause software to fail to compile. I keep getting caught out by these failures, and after making sure I have the latest version of Fink, doing fresh installs, permission repairs, etc., I finally remember to check the developer site for a new version.

I noticed on my MacBook (OS X 10.4.8) that the underlying UNIX based system (POSIX) was not going to update correctly for the Daylight Savings Time (DST) change in my time zone (America/Vancouver). To determine if your time zone has an issue, run this command in Terminal:

foo$ zdump -v /etc/localtime | grep 2007

If you see this in the output, then your DST will not start (or end) on the correct day:


Notice that those dates do not correspond to the second Sunday in March nor the first Sunday in November. Read on for a solution to this problem...

[robg adds: For those who aren't aware, DST will start earlier this year in the United States and most of Canada. From the Daylight Savings Time entry at Wikipedia (note the start and end dates for 2007):

DST commonly begins in the northern hemisphere on the last Sunday in March or the first Sunday in April and ends on the last Sunday in October. However, due to the Energy Policy Act of 2005, beginning in 2007, the United States will begin observing DST from the second Sunday in March until the first Sunday in November.

I looked at most of the US timezone files (Pacific, Central, etc.), and they all seem to be correct -- so many of you may not have to implement the solution explained in the remainder of this hint.]

Yesterday, I was doing some global editing on a relatively large text file, and accidentally made one change too many, saved changes, and quit the editor before I noticed the problem. The result? My file was now littered with sentences that ran together at the period:

...my bearers would hurl me.As they bore me along...
...glanced at the thermometer."Gad!" he cried...
...might make reparation.I made up my mind that...

For the curious, those lines are from Edgar Rice Burroughs' book At the Earth's Core, the text of which I'm using in a comment spam blocker I'm writing for my blog site. I was editing the text to remove some of the spurious punctuation that was causing my code to misinterpret the position of word breaks, and I got overly aggressive removing some spaces. Read on to see how I resolved it with some help from a friend, and the Unix underpinnings of OS X.

Last week, we ran this hint about using MacFUSE to install sshfs, which lets you mount ssh-connected servers like regular folders in the Finder. I tried it last weekend, and while I was generally thrilled with it (it's amazingly handy being able to work in remote folders as if they're local), I had some issues. In particular, it seems not to interact well with Path Finder (sshfs connections don't show as mounted volumes, for instance, unless they're in /Volumes, but they will do so in the Finder). I also had two kernel panics when I tried to unmount a mounted file system, so I decided to remove MacFUSE for now.

Unfortunately, there's no uninstaller included with the disk image distribution. After some rooting around on the MacFUSE site, I found these removal instructions on the Issues tab. I'm posting this hint mainly to say that I indeed tried the removal script posted there, and it seems to have worked well. I also checked the programs listed in the removal script against my MacBook Pro (which hasn't ever had MacFUSE installed), and found no overalp (so nothing listed there is used by anything else). The only extra step I took was to also remove the MacFUSE receipts from /Library -> Receipts.

There's a lot of promise in MacFUSE, but I think I'll wait a couple generations before trying it again!

Amit Singh posted an entry on his blog that mentioned the MacFUSE project -- the implementation of FUSE for Mac OS X.

Using the references that he mentions, one can have one's SSH account appear as a directory -- making it easy to handle and manage. Here's how...