Silencing Hazel
One of the main design precepts for Hazel was that it would do its work without bothering you and I feel I was successful in that goal, unless you are a developer. The one place where Hazel can get chatty is the console logs, much to the annoyance of some developers. I know how it can get in the way when you are trying to sift through your own application’s logs (though I do find that typing the process name into the search field does wonders).
Anyhoo, if you want to redirect the logs, you can use a defaults setting. Just type the following in at the command-line:
defaults write com.noodlesoft.Hazel LogFile file
file, of course, is whatever file you choose, including /dev/null. Removing the default will reverse the change. Note that this only applies to the background program; the UI, being a pref pane, logs wherever System Preferences logs, but it’s not nearly as talkative so hopefully this isn’t an issue. Also, there is no UI for this setting as I consider it to be something only developers would care about.
Random tangential reference to a piece of nostalgia/trivia:
When telling a friend (who was the one who brought up the original gripe) about this setting, I referred to the defaults setting as a dwrite which my friend found amusing (we’re both old NeXTies). In any case, along with dread and dremove, dwrite was the precursor to the defaults command and to this day I still refer to defaults settings that are only accessible via the command-line as “dwrites”. Old habits die hard.
Not-so-random, but nonetheless tangential info:
There’s another camp that would say that Hazel is too quiet. I am working on Growl support so if you have any particular opinions or ideas on the matter, let me know in the forums.
Category: Hazel, Noodlesoft, Software 3 comments »
January 15th, 2007 at 5:00 pm
I know I’m one of the people who has consistently complained about this noisy console behavior, but I beg to differ that it’s only something developers are concerned about. Sure, many users don’t even know what the Console is, but the point is it is generally used for exceptional information, not for the constant ramblings of any process.
It’s just messy to spew to the console. And I find it somewhat ironic that an application dedicated to keeping my computer clean would behave this way. I’m sure I’m not the only one, and I’m sure it’s not limited to developers.
I think you’re right that there shouldn’t be a switch in the UI. If you’re going to spray that much information, the default should be to log to a private log file that you can easily point customers at if they are having problems. Preferably this private log file should be maintained so that it doesn’t exceed a certain size.
Anyway that’s my 2 cents. Last time, I promise 🙂
January 15th, 2007 at 5:09 pm
I think Daniel’s suggestion makes more sense about having a private log.
I also kinda wish we had a “dread” command, just for the name 🙂
January 16th, 2007 at 3:24 pm
Thanks for the comments. Most of the current “spew” (actually, it’s mostly just one statement but it happens with every run of the background process) will be moved to debug level (there’s another ‘dwrite’ for setting this). I could then tell users when trying to diagnose a bug to turn debugging on. Errors would still get logged to Console.
Also, some spew is outside my control. If the background process crashes/terminates abnormally for any reason, launchd goes nuts with the messages. It basically remembers that it crashed and will remind you on every single run. Talk about holding a grudge. This problem will be moot as I’m going to be replacing launchd with a homegrown solution. You can read more about it in my comment at http://www.red-sweater.com/blog/245/taming-launchd