Next post Previous post

My trouble with Hazel

February 9, 2020 at 11:16 AM by Dr. Drang

I resisted getting Hazel for several years. Despite the praise it got from people I respect, it just didn’t seem like something I needed. My thinking, I guess, was that when I create or download files that need some action taken on them, I’m right there at the computer and can take that action myself. And maybe there will be times I don’t want that action taken. A system like Hazel wouldn’t be able to make decisions like that. Eventually, though, the siren call of deeper automation became irresistible. I bought Hazel 3–4 years ago, and over time I’ve set up a few rules that I think were truly useful. But Hazel’s unreliability at executing those rules has me ready to uninstall it.

Apart from some temporary rules I’ve used from time to time, I’ve had only three longterm uses for Hazel:

  1. To run my Southwest Airlines calendar event fixer, a script that edits the .ics files I get from SWA to include alarms that remind me to check in 24 hours before flights. This rule runs on certain .ics files saved to my Downloads folder and has never failed me.
  2. To copy ePub files that I make in Calibre to another folder so I can sync them with Marvin, the ereader I use.
  3. To add color tags to files with certain extensions so I can distinguish them in Files, which refuses to show file extensions except in the Show Info popup.

It’s the latter two rules that are unreliable, and I’m pretty sure I understand why. They don’t run on files in a particular folder, they run on files that are in some subfolder of a particular folder. Each tagging rule, for example, is really two rules, one that does the tagging,

Hazel rule for TeX files

and another that tells Hazel to run the tagging rule on all subfolders of my ~/projects folder,

Hazel rule for project subfolders

The reliability problem, I think, lies in the latter rule. While this is Noodlesoft’s standard guidance for processing subfolders, it seems more than coincidental that the only rules that fail are those that rely on this subfolder rule.

Unfortunately, I can’t get around this problem by setting up the tagging rules to apply to specific subfolders. At any given time, there are dozens of these subfolders, and new subfolders are made regularly as I work on new projects. Setting up new rules for these subfolders as I create them would be more work than just tagging the files by hand.

To get around Hazel’s unreliability for ePub files, I wrote a one-line shell script, epubs-update, that uses find and xargs to do the copying. I wrote about it before, but here it is again:

#!/bin/bash

find ~/Dropbox/calibre/ -iname "*.epub" -print0 | xargs -0 -I file cp -n file ~/Dropbox/epubs/

When I started having reliability problems with the tagging rules, I wrote a similar script, color-tags:

#!/bin/bash

find ~/projects/ -mtime -7 -iname "*.py" -print0 | xargs -0 tag --set Green
find ~/projects/ -mtime -7 -iname "*.tex" -print0 | xargs -0 tag --set Blue
find ~/projects/ -mtime -7 -iname "*.log" -print0 | xargs -0 tag --set Gray

This latter script uses JD Berry’s tag command, installed via Homebrew. It isn’t the most efficient script in the world—potentially setting tags on files that already have their tags set—but it does the job. I cut down on the inefficiency somewhat by including the -mtime -7 option. That limits the files found to just those modified in the past seven days.1

Since I’m always working at the command line when processing Python scripts and LaTeX files, running color-tags isn’t a burden—a Terminal window will always be open when I need to run it. And I suppose I could set up a launchd agent for running it periodically. We’ll see how I feel about it as I get more experience with it.

As for epubs-update, that’s clearly a command that needs to be run only after I add ePubs to Calibre. Probably the best way to launch it is through a Keyboard Maestro macro that’s active only when Calibre is.

The SWA calendar entry fixer doesn’t really need Hazel, either. Before I ever set up a Hazel rule for those .ics files, I was using a Service built with Automator to run it. I never deleted that Service, so it’s no big deal to return to it.

You could argue that since I own Hazel, it wouldn’t hurt to keep it active. But I see it as a waste of resources, even if those resources are minimal. And this is not a suggestion that you should stop using Hazel. If it works for you—and I’m sure it works for most of you—keep at it. But my three-year experiment with it is over.

  1. Why seven days? It was a guess at a decent compromise between completeness (where I wouldn’t include the -mtime option at all) and speed (the script takes over 8 seconds to run without the -mtime option). The purpose of tagging is to be able to distinguish between file types while working from my iPad, and this script is meant to tag files that I expect to see on my iPad. I seldom spend more than a week working on these types of files before moving at least once between Mac and iPad, so I suspect I’ll never need to tag older files. Again, this is a guess; I’ll need some time with it before I know if seven was the best choice. ↩

Next post Previous post