osascript will be able to display a dialog only if the user who is logged in and doing work is the same user you ssh'ed in as.

If you ssh joe@target.local, then your session can only see things that are in joe's Mach bootstrap namespace. If bill is logged in at the machine, the console (which includes the keyboard and the screen) is in bill's Mach namespace, and you can't see it. More precisely, what you can't see is the WindowServer.

This has absolutely nothing to do with users or privilege. Even if you su or sudo to become root, you are still in joe's namespace, and root's vaunted superuser privileges won't let osascript access a device it can't see.

So, when you send unix command via ARD admin and select to run as root, it doesn't work for you?

I don't have ARD, and know nothing about how it works. Since ARD has to be able to see the screen, I can only presume that when a new user logs in ARD's per-process namespace has its hierarchy changed so that it's now under that user's per-user namespace.

kaptagat is launching the script as a LaunchDaemon. Such a script would run in root's namespace, and would have no access to the WindowServer if a user is logged in. (That's why output from daemons is usually to a logfile.)

OK, thanks good to know. I will have to test some of this stuff out tomorrow when I am back in my office, if time permits of course.

thx

-T

I just tested this by logging into my iMac from another Mac, via ssh with a different user account. When I run this:

It works, even if I am not the same user. If I run it with out sudo I get the error failed to connect to window server.

I got the message popped up to me when ran as root.

That's weird. It doesn't work for me on 10.6.3.

So OK, I played with it some more. Let's suppose that the target machine has two users, Abner and Barney. Abner is an admin, Barney is not. Barney is logged in, and is using the screen. From another machine, I ssh to the target machine as Abner. All commands mentioned below are entered through that ssh session.

> osascript -e 'tell application "System Events" to display dialog "Hi"'
... error -10810 ...

> sudo osascript -e 'tell application "System Events" to display dialog "Hi"'
... error -10810 ...

> osascript -e 'tell application "Finder" to display dialog "Hi"'
... error -10810 ...

> sudo osascript -e 'tell application "Finder" to display dialog "Hi"'
I hear the target machine beep. I walk over and see Finder's icon bouncing in the dock. I click on the icon, and the dialog comes to the front. I click OK to dismiss it, and back at remote machine I see...
button returned:OK

That's not the behavior you're reporting, so I decide to explore variations on the theme. Using Fast User Switching on the target machine, I log in also as Abner, and then give control of the screen back to Barney, leaving Abner's session running in the background. Back at the terminal:

> osascript -e 'tell application "System Events" to display dialog "Hi"'
... error -10810 ...

> sudo osascript -e 'tell application "System Events" to display dialog "Hi"'
There's no immediate error, but the dialog doesn't pop up either, even if I hide all of Barney's windows. I use Fast User Switching to go back to Abner's session, and still didn't see a window. I pull up Activity Monitor and see that there is indeed an osascript process running as root. While I'm scratching my head wondering what to try next, the dialog finally pops up out of nowhere. I click OK, and back at the remote machine I see:
button returned:OK

Switching the target machine back again to Barney, I try the other variants

> osascript -e 'tell application "Finder" to display dialog "Hi"'
... error -10810 ...

> sudo osascript -e 'tell application "Finder" to display dialog "Hi"'
Beep. Finder icon bouncing. I click on bouncing icon to see dialog. Click OK:
button returned:OK

I never do see the "unable to connect to Window Server" message. Error -10810 is kLSUnknownErr, a catchall error result from Launch Services.

The only consistently useful result is with:
> sudo osascript -e 'tell application "Finder" to display dialog "Hi"'

It always works no matter who is logged in, as long as Finder is running. (If Finder isn't running, we're back to error -10810.) If Finder is not frontmost, it beeps and bounces its icon to get your attention.

Telling System Events to display the dialog doesn't always work, and even when it shows the dialog it doesn't bring it to the front.

This is what I did:

iMac 1 logged in as me, local admin

iMac 2 logged in as me, local admin

From iMac 2 I ssh'd into iMac 1 with a different account, one that is used for management purposes (also an admin account). If I ran the osascript command with out sudo I got an error, if I ran it with sudo it worked.

iMac 1 is 10.5.8 and iMac 2 is 10.6.3. Though, you are probably right on the finder always running, the problem with the finder is that it doesn't bring it to the front like you mentioned.

Also, as root if I run the say command it also worked for me.

So we're probably looking at a difference between 10.5.8 and 10.6.3.

But the advantage of Finder is that it will at least tell you that it has something to say if it's not already in the front. System Events is never in the front (unless your osa script explicitly activates it) and has no dock icon nor any other means to let you know it has a dialog it wants you to see. A dialog from System Events usually gets buried behind all the other user windows. (At least on 10.6. I don't know what it does on 10.5.)

Whichever one you tell to display the dialog, you can tell to activate first, so that's not a big deal. What is a big deal is that on 10.6 I can't get another user's System Events to display a dialog even using sudo.

It's probably better not to explicitly activate either one. The user we're trying to alert is probably in the middle of something, and won't appreciate having keyboard focus yanked away from him peremptorily. If Finder's not in front, it beeps and bounces its icon, but lets the user finish what he was doing. (Imagine a situation where the user is about to press the return key. If we activate Finder (or System Events) and put up a dialog at that precise moment, the user's keypress will dismiss the dialog they didn't have a chance to read.) Of course, they might not appreciate being kicked off the machine either, but at least they get to finish what they were doing. And isn't that, after all, what we're really after? Letting them finish before the machine restarts?

For historical reasons, there's a lot of overlap between Finder and System Events, the primary division of labor being that Finder now focuses on the GUI and foists everything else off onto System Events. Displaying a dialog is definitely GUI, so Finder is the one we should by rights be talking to anyway. Finder's response (beeping and bouncing its icon) is the correct behavior.