I recently installed a copy of the MySQL database server on my Leopard machine. The MySQL site offers a packaged version of MySQL 5.0.x for OS X 10.4 on their downloads page (current as of this posting: 5.0.51).

This 10.4 version works perfectly well with 10.5, except for some minor inconveniences. The first is that they include a preference pane for System Preferences, which doesn't work. They also offer to install a StartupItem to start the database server during boot. This works pretty well, except that Apple has marked StartupItems as depreciated since 10.4, noting that you should use launchd instead. There are many hints out there to create a launchd job using the MySQL supplied launchd_safe, which is basically a shell script for starting, monitoring, and restarting mysqld. That's a pretty ugly solution to start a server with launchd, and is actually discouraged by Apple.

So this hint is about replacing the StartupItem and the mysqld_safe script with a simple launchd job. It assumes you are familiar with the Terminal, logged with an administrator account, and have basic knowledge of launchctl and launchd.plist files. Also being familiar with MySQL configuration might help.

Diehard Unix gurus are going to be shocked to see Excel and the Unix shell mentioned in the same hint. Yet this can prove a very powerful combination for the average user. Unix gurus should read on, too. Say you want to remove a bunch of files from different locations in your file system, for instance, temporary files. The Unix way of doing things would be:

find -name "*~" -exec rm {} ;

We are doing nothing special here: find by name and then remove. Yet this bit of shell may be above the skill or the courage of many Mac users. In real life, you may want to do more complex searches (by modification date, in multiple locations, file type, ...), or do more complex operations (copy, rename, ...). You will quickly find yourself in need of a full-blown shell script which loops over the results from mdfind. Well, there is an easier solution involving HoudahSpot and your favorite spreadsheet (Numbers, Excel,...).

First, use HoudahSpot to formulate a query matching your files. You may create arbitrarily complex searches by combining criteria using boolean operators. You may search several locations at once, yet exclude others. Once you are satisfied with the result, configure HoudahSpot to show the file path column for the result list. (Control-click on the column headers in the results area, and select File Path from the pop-up menu.)

Advanced OS X users know that Darwin comes with ipfw, which can be used to set up a custom firewall. This same service however can be used to also limit bandwidth on specific ports.

Example:

sudo ipfw pipe 1 config bw 15KByte/s

creates a pipe that only allows up to 15KB/s to go through.

Then:

sudo ipfw add 1 pipe 1 src-port 80

will attach that pipe to the outgoing traffic on port 80, effectively limiting the outgoing traffic of the web server.

sudo ipfw delete 1

will remove the pipe from the port.

[kirkmc adds: I haven't tested this. Just make sure you remember to turn this off when you no longer need it!]

Leopard ships with an older version (1.4.6) of Gnu M4, the macro programming language used mostly by Gnu Autotools. You might therefore get this error when trying to build a configure script:

/usr/bin/gm4: INTERNAL ERROR: recursive push_string!
autom4te: /usr/bin/gm4 failed with exit status: 1

Once you learn that this is a well-documented bug in m4 1.4.6, you'll immediately go to the Gnu M4 Downloads page and retrieve the latest version. However, version 1.4.10 seems to have a bug which makes it fail to write most of the output on OS X 10.5 (even though it works fine on Linux). Instead, get 1.4.9, and all will be well.

Note that this problem is only going to affect people writing autotools build scripts, or building sendmail.cf files, or otherwise using M4. It has no effect on, for example, running configure to build a project you got from somewhere else.

I am currently using VLC for my streaming radio fix. As VLC does not update its track and title information, the are three ways for me to check the current streaming radio track. The first two are to Get info on the current stream in VLC, or use VLC's embedded message viewer, both of which require a lot of mousing around, aren't a quick view solution, and neither allow me to constantly see the changing track names.

The other is to write the message viewer's contents to a log. I was using a standard log file, but after constantly having to erase the file after it became too big, I realized that this going to kill the hard drive in no time, especially if I do the same thing on a flash-drive-based linux distro (Which I am planning).

After digging, I found out about FIFOs and named pipes, even seeing a hint here about them. I also read about how the GUI side of OS X does not handle named pipes graciously (Finder or VLC crashes). But reading around, I noticed pseudo terminals and had an epiphany. GUI apps can access /dev devices (such as sound cards and serial ports) by name, so why can't they write to them?

I end up assigning VLC to log to /dev/ttyu1 then I cat /dev/ptyu1. tail does not work on /dev/ptyu1 because the pseudo-terminal does not have an for it to work from, and cat keeps reading until it receives one (when VLC quits). This way, VLC in the GUI thinks I am logging to a file, and I can see what is being logged (via Terminal) without actually writing the log to the hard drive.

Some may be familiar the say command, where you simply open the terminal and type say (something) and your mac will speak. This is especially fun when you are logged in remotely via ssh, and someone is close to your mac at home.

Anyhow, by combining the say and date commands, you can then set up a cron job that will allow your Mac to speak the time at any interval you choose. I'm not sure if there are utilities out there that can do this, but this is certainly a good way learn how to use some of the Unix goodness in OS X.

[robg adds: You can set up a voice announcement on the Clock tab of the Date & Time System Preferences panel -- at least on the hour, half-hour, or quarter hour. Read on, however, if you're new to the Unix side of OS X and you're interested in learning a bit more about it. This solution also has the advantage of running for all users, not just for the logged-in user.]

I noticed that mdfind has become much more useful now in Leopard. For instance, you can run Finder saved searches from the command line. As an example...

mdfind -s "Pet Pics"

...will show the results of saved search called "Pet Pics." It actually looks for the saved search in ~/Library/Saved Searches, but you can give it a full file path if you wish. This means you can build up your queries visually using Finder, then easily use them in scripts. Also, you can give mdfind queries in the same language that you'd use in Spotlight:

mdfind -interpret "pet kind:image"

As usual, check man mdfind page for more info, but note that the man page is not consistent with all that mdfind can do (eg, it doesn't mention -s in the man page).

A lot of people have complained about ssh being slow when connecting to others hosts when you give a hostname instead of an IP address. The problem is obviously related to DNS name resolution. At my workplace, this might also have to do with the fact that we are using the .local domain for our network (which was decided long before Apple used it for Rendezvous).

However, I did not want to care where the problem really comes from, so I wrote a script that works around ssh's slow name resolution. It resolves the hostname using the host(1) utility, and calls ssh using the resulting IP address. Even after extensive web searching, I did not find out why ssh is only slow for some people (depending on various network and ssh config settings), so I do not really know whom this hint applies to. But it still might be worth a try if you think your ssh is slow when connecting, and you've already checked your DNS and ssh settings.

Put the following script into some directory in your PATH, for instance /usr/local/bin, name it ssh, make it executable by running chmod +x /usr/local/bin/ssh, and there you go.

#!/bin/zsh
destuser="${1%@*}"
desthost="${1/*@}"
shift
ip=${$(host "$desthost")[4]}
if [ "$destuser" = "$desthost" ]
then
       dest="$ip"
else
       dest="$destuser"@"$ip"
fi
exec /usr/bin/ssh "$dest" "$@"

There is a little bug I did not care to fix: The script assumes that your first argument will always be hostname or user@hostname. Any ssh options or commands must be given afterwards.

Given what I do for Macworld, I take a lot of screenshots. Sometimes I need to take those shots remotely -- for instance, to grab a screnshot of the login window, you must connect to a logged-out Mac via ssh, then use the screencapture command, as described in this older hint.

With 10.5, though, the rules have changed, as described in the man pages for screencapture:

To capture screen content while logged in via ssh, you must launch screencapture in the same mach bootstrap hierarchy as loginwindow:

      PID=pid of loginwindow
      sudo launchctl bsexec $PID screencapture [options]

So to take a screen capture, you need to first get the PID of the loginwindow, which you can do via ps ax | grep [l]oginwindow in Terminal. The PID is the first number in the output; assuming it was 935, you'd then execute sudo launchctl bsexec 935 screencapture, followed by your desired screencapture options.

Being the lazy sort, this seemed like too much work, so I came up with the following solution.

In my search for the nicest text editor, I have kept returning to Vim. I would use it for a little while, and then I would lose interest because something or another wasn't quite working the way I liked. This last time, I manged to solve all of those things, and I even found some extra features I didn't know about. Right now, I am using Vim.app (native GUI), version 7.1.161, with all the latest patches. Even better, I did not have to puzzle over configuration settings or anything to compile it - I just entered a command, and everything else relating to compiling was done automatically. How is this possible, you ask? All will be revealed...

Prerequisites:

• Developer Tools
• Over 64MB free disk space
• A high-bandwidth connection
• Some familiarity with the command line