osascript error over SSH in 10.2.8?

Hey people,

. Not sure if this is a version-related bug, but it seems like it might be. I’ve been trying to get osascript working properly on an old iMac G3 that we’re hoping to use to control some pieces of equipment. It’s currently running OS 10.2.8 (latest software updates and such).

. Using the following script:

#!/usr/bin/perl -w
osascript -e 'tell app "Finder" to activate';
exit;

. Finder is successfully brought to the front when the script is called locally. However, if I SSH into the machine, I get the following error:

CFMessagePortCreateLocal failed (name = Processes-0.3407873 error = 0)

. I don’t seem to get this on my laptop, which is running 10.3.5. Ideas? Workarounds?

. Thanks!

Check the iMac’s console log to see if you’re getting any permissions errors when you run this script remotely.

When you say you don’t see this on your laptop, do you mean when you run terminal on the laptop or when the laptop is the host?

. Sorry, newbie thing, but don’t really know where the console log is. I have Console.app open when I try (unsuccessfully) to run the script, and no error messages are shown. I’ve checked /var/log/system.log and there’s nothing posted when I try to run the script.

. With regards to my laptop, I try the same setup, but on a different machine running 10.3.5. That is to say:

→ on the 10.2.8 machine, I log in (through the GUI) with an administrator account, create a script with the given commands, try to execute it and it runs. if i then open a terminal window, ssh into the same machine, log in with the same account, it fails with the “CFMessagePortCreateLocal failed” error
→ on the 10.3.5 machine, I log in (through the GUI) with an administrator account, create a script with the given commands, try to execute it and it runs. if i then go through the ssh scenario, it works.

. I’m thinking that for some reason it should be trying to create a message port remote instead of local since I’m ssh’ing into the machine? That’s just a guess based on the little I’ve been able to dig up on google…

. Thanks for your time so far…

check

system preferences >> sharing >> Services : “Allows remote Apple Events”

…or something like that. don’t know what its called in the english system exactly.

I’m not too sure if that’s what you’Re looking for, nor if theres something like this in pre 10.3… but you might have a chance!

best wishes , mykuki

. I had originally thought it might have had something to do with a service not being up or a port being blocked, so I made sure to enable the services that seemed reasonable (Remote Apple Events, and Remote Login) and shut off the OS X FireWall completely, but it didn’t seem to change anything on the 10.2.8 system.

. On the flip side, I can have the Firewall up, and only Remote Login active on my 10.3.5 machine, and the script works just fine.

. On a side note, is this really a “Remote Apple Event” if I have already ssh’ed into the machine? Doesn’t seem like a remote event anymore since it’s originating from the very machine that is receiving the event…

ok, you’re probably right with it not being a remote event.

have tried anything else via ssh to the iMac?

have you tried anything beside pearl?

#!/bin/sh
osascript -e "tell application "Finder" to activate"

BTW why are you putting your whole line in `` ?
(i never did anything pearl or ssh myself… )

You’re right. This is not a remote apple event. Do you see anything in console when your request fails? Are you logging in as the same user from both machines (the one that works and the one that doesn’t)?

Seems to me that terminal is terminal. It shouldn’t matter what OS the terminal app is running on. All the commands are going to an SSH to the same host.

What user are you running the command under and, more specifically, what user is currently logged in at the desktop?

IIRC osascript will try to bind to the WindowServer even if the script you’re about to run is completely faceless. Since there can only be one WindowServer running, and two users can’t ‘own’ the same WindowServer, this will only work if you login via SSH using the same UID as the current user on the desktop.

The alternative is to run as root since root has the ability to bind to the WindowServer of another user.