Custom Log File Revisited
After my log file post last week, I had a few people approach me with questions or good suggestions. So I’ve made a few updates and thought I would share them once again.
Formatting
Reader Patrick Mosby sent me an email in which he asked this:
I just read your article “Track Yourself With a Custom Log File” and wondered how you get the formatting of the entries like you showed in your screenshot. Are you typing this everytime by hand or do you also have some kind of automation?
I tried to use TextExpander to expand “ttime” to the current time but it seems that it doesn’t work in Quicksilver’s text input field.
Good question. Patrick was referring to the time stamps in each entry. In the beginning I was entering them in by hand, but since I have TextExpander, I wanted to make use of it. He was right though—it doesn’t work by default in the Quicksilver text input field. But with a bit of playing around, I found that if you prepend your TextExpander snippet with a period, they work just fine. The period invokes the Quicksilver text input, but also is the character for invoking your snippet.
In this example, typing ‘.ttime’ works perfectly.
Automation
In my original setup, I had created an iCal event that had an alarm that would trigger an apple script to run. This apple script updates a few different text files with the current date.
Jamie Phelps asked me via Twitter if I would consider using using a launchd daemon instead of an iCal event. Why? Well, most importantly, this event clutters up iCal. Using a daemon would be a cleaner solution.
I’m always up for increasing the UNIX skills, so I took on this challenge. After several hours of research and tweaking, I’ve got a solution that works nicely. Hardcore command line geeks can start laughing here—for those in the know, this type of automation is elementary. But I’ll include some details for those folks like me—people who are comfortable working in different applications and the command line, but are not familiar with all the commands and utilities.
First off, the idea with a plist file is that it tells launchd what to run and when to run it. I found out that much before getting to some documentation. Here’s a list of resources I used:
- Started with launchd on wikipedia and apple.
- Moved on to the OS X man pages, specifically on launchd.plists and launchctl.
After all that reading, I had a plist file that looked like this:
After creating this file, you have to load it from Terminal using launchctl:
Unfortunately, even though the plist file appeared to be working, the log files were not updating. After much playing around and testing, I gave up and posted my issue on the Apple support forums. After a couple more hours and several replies back and forth with some very helpful folks, I had all my questions answered.
You have to love the Mac community. This whole process would have been much faster if I had started on the forums rather than starting with Google. Here’s what I learned from these people.
plist Creation
When creating a plist file that will launch an app or script file, rather than build it from scratch in Property List Editor (an application included with OS X), it was strongly suggested to create them with an open source third party app named Lingon. The app gives you a couple of options (what do you want to run and when etc.) and adds in all the correct elements for you. This is much easier than the guessing I was doing, trying to figure out which parameters to include.
Here’s a shot of Lingon in action:
Here’s how the plist files looked after creating it from scratch in Lingon:
You can see there were a few more parameters included this time.
Console
Even after creating the plist file in Lingon, the whole process still wasn’t working—the text files were not updating. I was asked to use Console (another application in OS X) to look for any messages being generated by launchd. Sure enough, error messages were being generated:
Permission denied? I couldn’t guess why that would be the case, since all the files involved had the same permissions set. But again, the folks on the forum led me in the right direction. Turns out launchd will run an application with just the path, as long as the file ends in ‘.app’. Otherwise, if you have a script file with an extension of ‘.scpt’, you need to add the string value of osascript as shown in the last screenshot of the plist file (this is the command you would use to run a script file from the terminal). Added that parameter and presto—it works perfectly.
Making a short story long, I would have saved myself some time if I had known to use Console to troubleshoot this. But that’s how learning goes, yes?
So finally I had an automated solution to add a daily date stamp to my log files. Sounds like a lot of work, but I like to learning this type of thing. So I consider it time well spent.
One last thing to mention.
Display
Although I’ve seen a lot of people use utilities like GeekTool to display files on their desktop, I’ve never been much interested myself. But with this log file, I thought it would be handy to be able to see my activities without having the file open all the time (I never have it open because I’m adding entries via QS). In addition, I created a MIT file, drawing upon the idea of having a big rocks or most important tasks list for each day.
So I installed and configured GeekTool and now have a visual of these two lists always on the desktop.
So there you have it. A lot of learning and twiddling just to keep a simple text file. But for me, these are skills that, once learned, make things easier—and faster—down the road. And I hope that the idea of the text based log file will prove itself years from now.
Heck, I even got an email from Matthew Cornell, he of the big arse text file that started this whole thing. Ask him how valuable his log file is after all these years.
I think that’s worth the time up front.
