Terminal Heaven Part 1: Homebrew
Despite the fact that Mac OS X has a fantastic and beautiful GUI, as a software developer I have to use the shell all the time. When I started on the Mac I was using the de facto standard setup which includes Terminal.app, Bash and MacPorts. This setup lasted for nearly 3 years but got now replaced for a much better one:
Lets start the first part of this mini series with the reasons for my move to MacPorts.
One of the biggest system changes I have done this year was moving from MacPorts to Homebrew. I was using MacPorts from the beginning of my Mac life to manage the installation of all those cool and useful unix programs I need for my daily work. But there was one thing which really bothered me. Every time you were doing a package update there were so many updates available that it always took ages to compile on my machine. And for most of the packages I really had no clue what they were doing. Most of them just seemed to be dependencies from packages I had installed.
After reading a lot about Homebrew on the net I decided to give it a try. The main advantage of Homebrew is that it only installs packages which are not already present in the Mac OS X system. So you don’t get any duplicates of libraries and programs on your system unless it is really necessary.
I also like the fact that a simple:
> brew update && brew outdated
updates the local git repository and then gives me a list of all outdated packages where I can handpick the ones I want to update. As all programs and libraries are compiled against your existing system libraries this speeds up the update process enormously.
There is one thing about Homebrew which I really don’t like that much. The developers of Homebrew favor not to use the sudo command for all homebrew operations. As convenient that is for installing and updating packages, lowering the security on /usr/local makes me feel uncomfortable. I know that for installing and updating packages it’s much more secure to not use sudo because giving an unknown script root access is always unsafe. What I don’t like is that every program I run as a normal user can change the content of /usr/local without me even noticing it.
After using Homebrew for a couple of months now I can say I’m really happy with it. The package list is constantly growing and the community is very good.
Stay tuned for the next parts of this series!
- Terminal Heaven Part 2: iTerm2
- Terminal Heaven Part 3: zsh and oh-my-zsh
Howto fix Growl Mail for 10.6.5
Update for 10.6.7: Please try MailPluginFix to enable GrowlMail again. This should be much easier.
Apple today released Mac OS X 10.6.5 which includes an update to Apple Mail 4.4. As always this update disables all incompatible plugins including GrowlMail. Actually the GrowlMail plugin is still working with the new Mail version you just have to include the new Mail UUIDs into the plugins plist file.
Have a look at my last blog post how to get the new UUIDs and how to fix the plugin.
Here are the new UUIDs for Apple Mail 4.4:
- BDD81F4D-6881-4A8D-94A7-E67410089EEB
- 857A142A-AB81-4D99-BECC-D1B55A86D94E
Howto re-enable Mac Mail plugins after updates
Update for 10.6.7: Please try MailPluginFix to enable GrowlMail again. This should be much easier.
Today I upgraded my MacBook to the new released Mac OS X 10.6.4. Everything worked fine except that the update contained a new version of the Apple Mail application which disabled my GrowlMail plugin (not for the first time!). As I really need this plugin and I didn’t want to wait for an update I did a little web research and came up with the following solution:
- Quit the Mail application
- Get the UUID of the new installed Mail and and Messages.framework
To do this open the Terminal application and execute the following two commands:
$ cat /Applications/Mail.app/Contents/Info.plist | grep UUID -A 1 $ cat /System/Library/Frameworks/Message.framework/Resources/Info.plist | grep UUID -A 1
You will find the UUIDs between the two string elements. For Mail 4.3 I got:
B842F7D0-4D81-4DDF-A672-129CA5B32D57
E71BD599-351A-42C5-9B63-EA5C47F7CE8E
- If the plugin already got moved to “~/Library/Mail/Bundles (Disabled)/” move it back to “~/Library/Mail/Bundles/”
- Open “/Library/Mail/Bundles/GrowlMail.mailbundle/Contents/Info.plist” with the Property List Editor (If no editor opens on double click you probably have to install the Xcode tools from your Mac OS X DVD)
- Insert the two UUIDs under SupportedPluginCompatibilityUUID and save the document
- Start the Mail APP and be happy :-)
This should also work for other Mail plugins. But if the plugin is incompatible with the new Mail version you will probably have problems starting Mail. If this happens you will have to remove the plugin again and you will have to wait for a plugin update.
As always try this at your own risk and don’t forget to make a backup before you start. Good Luck!
