Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Avoid AppleScript command errors when used via SSH UNIX
I finally figured out why I wasn't able to run AppleScript commands when I SSHed into one of my systems. Here's what I was seeing:
$ say hello
Bus error
$ osascript -e 'say hello'
CFMessagePortCreateLocal failed (name = Processes-0.20971521 error = 0)
Abort trap
At first, I thought this had to do with user security, but they still failed when putting sudo in front of them. Doing some reading, I figured out that this has to do with process groups. You can only run AppleScript if your process is in the same group as the user logged onto the console. In my case, I was trying to run the AppleScript from within a screen session, and screen somehow creates its own process group(s).

Accordingly, run the AppleScript commands from outside screen, and it all works. Took me ages to figure this out...
    •    
  • Currently 1.50 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[6,574 views]  

Avoid AppleScript command errors when used via SSH | 5 comments | Create New Account
Click here to return to the 'Avoid AppleScript command errors when used via SSH' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Avoid AppleScript command errors when used via SSH
Authored by: geohar on Nov 10, '04 09:30:37AM

I run applescript under screen the whole time! But you are right, the console user and your user have to match. The thing that seems to happen is that the process group of the shells under a reattached screen sometimes don't seem to be right. Not quite sure if that's a bug in screen or not.

BTW fink has a better version of screen than the one installed with X, and has XTerm mouse passthru fixed (so you can use the mouse via PuTTY or whatever to edit in vim and emacs).



[ Reply to This | # ]
Avoid AppleScript command errors when used via SSH
Authored by: MartySells on Nov 11, '04 01:54:51AM

Wow. I hadn't tried all the different combinations.

Applescript (say) worked for me under screen this time! Even after a detach & reattach from the same SSH session. It does, however, fail if you exit the SSH session that you created the screen in and reattach from another one. If you leave the SSH that created the screen open it does work after a reattach. I didn't look through 'ps -j' to figure out what exactly is going on.

-m



[ Reply to This | # ]
Avoid AppleScript command errors when used via SSH
Authored by: noxon on Nov 11, '04 08:12:20PM

I've seen this myself, as i use IRC within a screen. The irc then uses osascript as an exec command to get itunes tracks to display, and it is very annoying when it happens.



[ Reply to This | # ]
Avoid AppleScript command errors when used via SSH
Authored by: geohar on Nov 12, '04 04:32:01AM

It's probably worth having a play with the setsid setting for screen - see man screen, excerpt below:

setsid [on|off]

Normally screen uses different sessions and process groups for the win-dows. If setsid is turned off, this is not done anymore and all windows will be in the same process group as the screen backend process. This also breaks job-control, so be careful. The default is on, of course. This command is probably useful only in rare circumstances.

Hmmm.

I believe it's the session ID that prevents the mach-port opening (for security reasons, mach-init will not allow you to negotiate a port between different login session ids - each user logged in has a separate one and it'd allow you to mess with another user's programs).

Looking at the screen source, I think this controls the pgrp allocations also.


George



[ Reply to This | # ]
Avoid AppleScript command errors when used via SSH
Authored by: geohar on Nov 12, '04 06:33:00AM

My bad. Actually the sid and pgid that ps reports are not (directly) related to the security session ID that you can't 'talk' across.

When I log in remotely I get a different session ID each time. When you detach and reattach you get a new security session ID - it's sshd that spawns a new one on accepting a connection. Each shell/window within screen will share the same security session ID though.

On the original login, screen a session with the tty and is registered as being a remote-initiated connection.

Now when reattaching back to a detached screen session, the session properties are 'root'. A little worrying I think you'll agree. Now because root isn't the user logged in on the 'console' (ie. the graphically logged in user), you can't open a mach port to the gui (which is what applescript needs, reguardless of whether it uses any GUI). However, I believe this flag doesn't result in escalated privalidges, it just implies this is a startup session (the one that spawns all others). As such it can't talk to the session with the GUI.



[ Reply to This | # ]