Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

  (email not shown publicly)
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Monday May 20, 2002
04:28 PM

Stupid Mac OS X AppleScript

[ #5104 ]

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 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:

tell application "iTunes"

I have:

tell application "iTunes" of machine "eppc://"

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@; 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@, 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!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • When selecting a password, I tend to sit down with a random number generator and an ASCII table. Really. As a result, I've occasionally had problems with interesting characters in certain situations. I remember problems with @ and >, and one great time when I couldn't seem to log into a sun machine because my password contained ~ and it was in a different spot on the keyboard. :)

    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers