I bring my iBook everywhere, and I store on its drive 80% of my important data, since I use it for studying, working, scripting, doing projects for university, listening to music, downloading stuff, browsing, printing nice articles found on the Web to PDFs, etc. Scared by the fact that hard drives fail when you least expect it -- and trust me, they still fail if you (like me) love your hardware more than your girlfriend. So I spent some days thinking about and coding a little script-based backup system with the following features:

• low memory usage
• fast!
• capable of backing up several directories in a single .iso image, ready to be burned.

My files-to-backup and my backup files must be stored on the same hard disk (the 40GB one inside my iBook), at least until I burn them on CDs every weekend. So, to prevent useless duplicates floating in my laptop, and my confusion during my several daily Spotlight searches, I chose to back up to a disc image (i.e. a single explorable file), instead of a "normal" method of back up (with duplicate files/folders, usually on another drive).

I chose the ISO format instead of a disk image, because the first one is a more standard kind of disc image compared to the second one. It can be mounted and explored or burned on both Mac and on Windows machines (using the nice freeware tool called Daemon Tools, for example). Why did I code a script instead of using one of the tons of backup apps out there? Because the ones I tested don't do exactly what I need, and because doing the things I need myself and watching them work wonderfully makes me happy like a child who has finally received its most-wanted toy from Santa Claus! And by the way, scripting on Mac OS X is so easy that you can't really stop doing it once you get started.

I'm frustrated and surprised that the problems with apropos have still not been fixed. I noticed this was discussed here before, but apparently those fixes don't work on my current install of Mac OS X 10.4.9. Using ideas from the prior hint, I added the following as a fix in my .bash_profile:

function aproposFunc() {
  width=`stty size | cut -d  -f2`; apropos $* | cut -c1-$width;
}
alias apropos=aproposFunc

Background:

For those not aware, the problem causes many lines (or pages) of extra information to be printed when you execute apropos key. The prior fix involved limiting the line-length as a pipe after the $PAGER variable (i.e. less), or using the -S command-line option. The current implementation of apropos no longer uses the $PAGER variable, but instead becomes a grep on a large text file at /usr/share/man/whatis. That text file is built by a system process, but perhaps ends up with the over-extended lines because of problems between makewhatis and the man pages' formatting.

[robg adds: This one didn't work for me in testing -- apropos serial returned the same long text as it did before ... if anyone can fix the code, please post in the comments. Note that I had to add single quotes around the alias entry in my .profile file to get the alias recognized.]

Remarkably, there are many pitfalls in the tools currently available to back up OS X. I ran into difficulties with several recommended backup solutions, such as the popular Carbon Copy Cloner and others. After poking around the web, I found a shell script solution based on rsync that works fine for me.

Here's my version of it. It keeps two older backups, and uses hard links for all unchanged files to avoid unnecessary duplication. Edit it in the obvious way to put the backups where you want them. Also, you must run this script as root.

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

I recently got a new ISP after a house move, and have always had a cron job running to back up my files each day to an online server. Previously, I would have this job (rsync) run and pipe the output automatically to the mail command, which would throw it out to my inbox, allowing me to automatically see if there was anything wrong with the sync.

With my new ISP, they have this annoying habit of blocking any emails that look like they are coming from an SMTP server that is not their own. Obviously, so they do not get spammers blacklisting them, and hence not even their SMTP servers would be allowed to send mail, or their mail would not be accepted. This poses an issue for tech savvy people who may know what they are doing, but are being punished for knowing how things work.

Hence, I stopped getting my emails to say how the sync had gone. After getting annoyed by this, I started to look into it further. It seemed that if I was on a different network, for example my university one, and the job ran, the email would not get through -- at least not until I got home, at which point I would receive the email (the other network was blocking all smtp email; it is smarter than my ISP).

After examining the headers of the email I did receive, I noticed that the "from" address was not the normal root@robs-powerbook.local, but had rather taken on the domain of the network I was on. You can see where this is going. If you use the -r command in the mail command when piping information to it in cron, you will get a senders address that you specify. So here is my modified command (line breaks added for readability; enter as one long line):

sh /Users/rob/bin/backupjoyent.sh 2>&1 | 
mail -s "Daily Backup to joyent report" my@domain.name 
-r sender@address.here

If you set the two email addresses to be the same thing, i.e. the email address you want to send to, you should get an email from yourself every time it is run. This may not work on all hosts, but it may help with some!

There have been a few hints on the site regarding using the CLI-based email client mutt, but they've typically been little snippets about how to accomplish certain things. Being an avid mutt user on Linux, and then on OS X, I've written an article called Using mutt on OS X, which is a full guide on using mutt, covering everything from mutt configuration (with sample configuration files), to setting up fetchmail and procmail, to even tweaking the postfix MTA (or installing and using exim instead).

It details a number of OS X-specific items, such as integration with Address Book, being able to automatically open attachments from mutt, etc. A few of these are from previous hints that ran, but this article takes you from having never used mutt all the way to being able to power-use it.

Using mutt gives you the most rich and flexible email client experience currently available on OS X. Yes, it's a commandline client, and as such doesn't have all the mouse clicks and sounds and whatnot that something like Mail.app would have, but it's stable, handles huge mailboxes, and is customizable like you would not believe.

The nice folks at cups.org have made a good installer package for the latest version of CUPS, 1.2.8. This version is newer than the version of CUPS included in Mac OS X 10.4.8, and offers features like: The ability to move jobs from queue to queue via the web interface (https://localhost:631); secure access via the web interface; and the ability to set print dialog default selections on a per-queue basis.

You may find it useful, especially if you use a Mac OS X or Mac OS X Server system as a print server. However, the installation isn't perfectly smooth, and it breaks some conventions that the Apple-supplied CUPS uses. Read on to see what breaks, and how I worked around those issues...

At one time, OS X didn't consult the hosts file before doing a DNS lookup. In 10.3 and 10.4, it does. You can check the name resolution order of your Mac using Terminal; enter the following:

lookupd -configuration

Look for the following in the output:

LookupOrder: Cache FF DNS NI DS
_config_name: Host Configuration

The FF (flat file) refers to your hosts file (/etc/hosts), and Tiger does check its contents before going to DNS and Netinfo. Just a little FYI for those who may not have realized that 10.4 fixed things.

I recently wrote a command line utility called webarchiver (free, source code available) that allows you to create Safari .webarchive files from the command line. Webarchives are a convenient way to store a webpage and its associated files (images, css, javascript, etc) in a single file. It is very simple to use:

./webarchiver -url http://www.google.com -output google.webarchive

Make sure you include http:// in the URL when fetching a remote webpage. If you don't, webarchiver attempts to locate a local file. Webarchiver is only compatible with OS X 10.4, and is a universal binary.

[robg adds: This worked as described in my testing.]

So you have Boot Camp and a big disk to use, but then you are bound to the NTFS format instead of FAT. But Mac OS X 10.4 can only read, not write, to these kind of formatted volumes. Follow these steps and you will be able to write to them as well:

1. If you choose to compile yourself, install Xcode 2.4.1, and especially the SDK package within it. Also, compile the latest release of pkgconfig.
2. Download MacFuse. Compile it yourself, or easier of course, is to download the binary .dmg file.
3. Download ntfs-3g and compile it -- there's also a premade binary .dmg if you prefer.
4. In Disk Utility, check out the device identifier (disk0s2 or something) of the NTFS volume, and unmount it.
5. In Terminal, type mkdir /Volumes/your_ntfs_volume, where your_ntfs_volume is the name of your NTFS volume.
6. Still in Terminal, type ntfs-3g /dev/disk0s2 /Volumes/your_ntfs_volume -o ping_diskarb,volname="your_ntfs_volume".

Normally your volume should be mounted. If not, type disktool -r and killall finder. To unmount, use sudo umount /dev/disk0s2. Use AppleScript if you want to facilitate mounting and unmounting.

[robg adds: I haven't tested this one, and would caution that if you plan to test it, you have a good backup before you begin.]

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?