Stupid Mac OS X AppleScript
I moved all my MP3 serving to my Mac OS X box instead of the Linux box, set up Apache::MP3, etc. One thing I had left to figure out was how to update pudge.net with whatever I was listening to at the time. I wrote a subclass for Apache::MP3 called Apache::MP3::Log some time ago, which would catch the request, log it on my home page, and then handle the request as normal. But since I have my MP3s local now, I don't bother with Apache::MP3, I just use the Library in iTunes (which, despite iTunes' UI problems, is very fast and easy to use, once you get the hang of it).
So I went back to my old method of using a cron job. Write an AppleScript that spits out the info I need, write a Perl script that calls the AppleScript with osascript (command-line tool), parses it out, pushes it to the web server. Easy. Except that osascript -- as well as some other command-line tools -- doesn't like to talk to iTunes when called from something other than the current session. So cron, or telnet/ssh sessions, etc. can't do it.
I figured I would try talking to iTunes via AppleScript over the network, then. Instead of:
This is clearly a bug in Mac OS X somewhere (I suspect the AppleScript library, or somesuch, since it does work in Mac OS 9). Anyway, so I created a new user, set a more simple password, used eppc://pudge2@127.0.0.1, and when prompted for the password, I typed it in, and told the Keychain to save it for future use. Finally, it works. The cron job might still fail if I am not logged in, so the Keychain is inaccessible, but I am always logged in on this machine sitting on my desk, so no worries.
Update Darnit. The password thing is not working. There's something called AEServer which handles the requests, and it keeps dying and leaving zombie processes. Then I can't authenticate. I think that maybe the script is trying to connect to one of the zombie AEServer processes. Anyway, so now I've reverted to having two processes running; one an AppleScript application from my login session that writes the data out to a temp file every 60 seconds or so, and another the perl script from a cron job that reads that data and deals with it, instead of calling the AppleScript directly. Stupid Mac OS X AppleScript!
So I went back to my old method of using a cron job. Write an AppleScript that spits out the info I need, write a Perl script that calls the AppleScript with osascript (command-line tool), parses it out, pushes it to the web server. Easy. Except that osascript -- as well as some other command-line tools -- doesn't like to talk to iTunes when called from something other than the current session. So cron, or telnet/ssh sessions, etc. can't do it.
I figured I would try talking to iTunes via AppleScript over the network, then. Instead of:
tell application "iTunes"I have:
tell application "iTunes" of machine "eppc://127.0.0.1"That should work, but it doesn't. It works from Mac OS 9, but not from Mac OS X. I try everything, to no avail. Finally, I find a "blog" entry through a Google search where someone had a similar problem. He did the same thing as me, though, except that he used eppc://user:password@127.0.0.1; I had been relying on the Keychain. This is where the light went on: I can't use this syntax directly, because my password has an @ in it. I try that syntax, using %40 in place of the @; still no love. So I change my password to something else. Ka-ching! It works. Bah! So now I can't have a certain password?
This is clearly a bug in Mac OS X somewhere (I suspect the AppleScript library, or somesuch, since it does work in Mac OS 9). Anyway, so I created a new user, set a more simple password, used eppc://pudge2@127.0.0.1, and when prompted for the password, I typed it in, and told the Keychain to save it for future use. Finally, it works. The cron job might still fail if I am not logged in, so the Keychain is inaccessible, but I am always logged in on this machine sitting on my desk, so no worries.
Update Darnit. The password thing is not working. There's something called AEServer which handles the requests, and it keeps dying and leaving zombie processes. Then I can't authenticate. I think that maybe the script is trying to connect to one of the zombie AEServer processes. Anyway, so now I've reverted to having two processes running; one an AppleScript application from my login session that writes the data out to a temp file every 60 seconds or so, and another the perl script from a cron job that reads that data and deals with it, instead of calling the AppleScript directly. Stupid Mac OS X AppleScript!
Leave a comment