As far as I know, when sending commands to an application on a remote machine, the application must be running. Maybe you can simply tell the Finder to open the script.
– Rob
Thanks, I guess that explains it then. I didn’t think I magically got past authentication. Back to square one. This is extremely frustrating and should not be rocket science. If it were my choice I’d use ‘rsh’.
I don’t have two OS X machines to use for testing but this works for me when sending from OS X to OS 9.
using terms from application "Finder"
tell application "Finder" of machine "eppc://user:password@192.168.0.102"
run script file "path:to:script"
end tell
end using terms from
– Rob
Thanks. I don’t see why OSX to OS9 makes a difference but I have exactly the same thing (OSX to OSX) except the “using terms”. I added that but no joy.
I don’t know if there is a difference or not. I suspect that there’s something very simple at the root of the problem. I am not insinuating that you don’t know what you are doing but this situation begs for basic troubleshooting. The simple things can be very easy to overlook because we sometimes don’t bother to check them.
- Are you using the user/password for your account on the remote machine?
- Could it be a permissions problem on the remote machine?
- Does your latest attempt with “using terms” even compile?
- Are you sure that you are using the correct IP address for the remote machine?
– Rob
Why? I don’t. 
- Yes (as I said, I can mount volumes using the same user/password)
- I created the script on the remote machine using the same user that is in the local script. The owner is the same as the one I’m using in the local script.
- Yes.
I am getting back into this thread kind of late. Here is what I know.
I use 2 different methods for applescript over IP.
The first is the “Run via Finder” - which is more like controlling the Finder and not so much the script.
using terms from application “Finder”
tell application “Finder” of machine “eppc://username:password@10.1.0.1”
activate
display dialog “X”
end tell
end using terms from
–you can use further this by having “Finder” run a script file, like the one on joeschmoe’s desktop, and passing it parameters
using terms from application “Finder”
tell application “Finder” of machine “eppc://username:password@10.1.0.1”
activate
run script file “machardrive:Users:joeschmoe:Desktop:testscript” with parameters {“something”}
end tell
end using terms from
This will cause the Finder to run the statements contained in the script. You won’t see any script application bouncing in the dock or anything. There isn’t a way I know how to stop or interfere with the script commands that I know of.
Now, the way I understand it, the “using terms from” provides a way to compile the script by using the dictionary from the local application. I am not completely sure if it even applies in OSX. (confirmation on how this works anyone?)
If you want to tell a “script” to do stuff, then you need a stay open application, and you talk to it, without talking to the Finder, or even the “using terms from”.
Just make sure the app is running on the remote system before you try to compile.
tell application “myscript” of machine “eppc://username:password@10.1.0.1”
activate
myScriptHandler(parameter)
end tell
So putting all of this together:
If you just want to run a script and quit, then you probably want to tell the “Finder” to run script. Start by writing 2 scripts. Script A is the script that does the work you want to do. Script B is
tell application “Finder”
activate
run script file “localmachardrive:Users:joeschmoe:Desktop:testscript” with parameters {“something”}
end tell
When you are satisfied how it works Script A works, save the script as a compiled script and place it on the remote machine. Then change Script B to
using terms from application “Finder”
tell application “Finder” of machine “eppc://username:password@10.1.0.1”
activate
run script file “remotemachardrive:Users:joeschmoe:Desktop:testscript” with parameters {“something”}
end tell
end using terms from
Or the other approach is to write Script A, and give it a handler like:
on doSomething(theText)
tell me to activate
display dialog theText
end doSomething
Save as a stay open application and let it run.
Write Script B like this:
tell application “myscript”
activate
doSomething(“Hello World!”)
end tell
Again, when satisfied that all works, move Script A to the remote machine, start it, and change Script B to
tell application “myscript” of machine “eppc://username:password@10.1.0.1”
activate
doSomething(“Hello World!”)
end tell
This may be overkill explanation, but I hope something in it will help. Just for the record, the only thing you need turned on in the Sharing Pane of System Prefs is Remote Apple Events on the remote machine. I can get this to work with Personal File Sharing turned off on both machines, and Remote Apple Events turned off on the local machine.
Best of luck.
Thanks for a great explaination. It cleared up a few misconceptions on my part and filled in a few holes. Unfortunately, it does not address my primary problem which is getting past authentication. Since I know the username and password are correct and work everywhere except in this script I have hit a wall. Although my client does not want Unix commands involved I am using ‘ssh’ and ‘osascript’ as a stop gap measure until I can get this figured out.
Why doesn’t your client want UNIX commands involved? It may simply be a matter of educating your client. If all you need to do is start executing an autonomous script on the remote system, it seems to me the SSH/osascript approach is every bit as good as the remote AppleScript solution, and potentially better as it might be more secure. But if you need to send and receive AppleEvents between the two systems, remote AppleScript may have an advantage. YMMV.
Mostly because when I’m finished and gone they won’t have any one who knows Unix. Getting ‘ssh’ to work is a non trivial exercise (setting up the right keys in teh right place, etc.) for the Unix novice, so if they want to port it to another server it won’t work without Unix mods.
My question at this point is: Why shouldn’t I be able to use Applescript?
I should think you ought to be able to get AppleScript to work, but then i’ve never actually played with remote AppleScript! Never have had a need, and i am not entirely trusting that its transport technology is secure.
But i really don’t think the reasons you cite are sufficient to not use any UNIX commands, especially if you do a good job documenting what you’ve done. You’re only using a handful of UNIX commands. And one can glean what you’re doing fairly easily without having to “learn UNIX” in general (assuming you document it well enough). That’s not really any different than using advanced AppleScript techniques they might not understand at first. If they can’t understand that much UNIX, then they probably can’t understand your AppleScript code either. And insomuch as MacOS X is UNIX, your client will not be able to avoid learning some UNIX eventually anyhow.
Regarding the keys and the proper directories, why don’t you just write an AppleScript to install them? You can even embed the public key into an AppleScript applet, and simply run the applet on each target machine. (Just make sure your applet appends the key to any pre-existing file, rather than overwriting it, and you should also check to see if the key is already installed, so you don’t add duplicate copies; a simple grep call can check this).
If you’re billing your client for the hours you’re spending trying to get this going, you’d be doing them a better service, in my opinion, by cutting their losses, get it going by using a little UNIX, and spend the time to properly document what you’ve done. Same goes for you, if you’re not billing them for the time.
Just my 2¢ worth. YMMV. Best of luck!
I guess it is not “any” Unix commands but remote shell commands. I can understand their reticence. I explained the issue about setting up keys. Then, since their ISP does not provide reverse DNS, I started explaining /etc/hosts and resolver and before I finished they were rolling their eyes. There is a lot of detail to make remote shell work.
There is an old saw as well: The customer may not always be right but the customer is always the customer.
Mostly because I haven’t done that before and it means another learning curve and perhaps another brick wall (see below).
That is turning out to not be simple either. See: http://bbs.applescript.net/viewtopic.php?t=5514
There is no way this should so hard. If it were Linux or Windows I would have finished weeks ago.
You can use an IP address instead of a domain name in SSH, if you like. DNS resolution is not necessary.
Fair enough, but you do have a couple of options in manipulating files: AppleScript or UNIX.
You know exactly where the file should be: .ssh/authorized_keys, and each line is a key. All you have to do is check each line of the file to see if your key is already in there. If it is, you’re done. If not, append your key to the end of the file. To do that the UNIX way, you’d do something like:
do shell script "echo " & quoted form of theNewKey & ">> .ssh/authorized_keys"
The “>>” tells UNIX to take the output of the echo command and append it to the file which follows (creating it if it doesn’t exist). To check for the existence of the key in the file, you can use AppleScript, or UNIX. The UNIX way would most likely use grep and look something like this:
if test ! -d .ssh; then mkdir -m 700 .ssh; fi; if grep -q "[i]theNewKeyGoesHere[/i]" 2> /dev/null; then; else echo "[i]theNewKeyGoesHere[/i]" >> .ssh/authorized_keys ; fi && chmod 600 .ssh/authorized_keys
The if test ! -d .ssh; then mkdir -m 700 .ssh; fi block creates the .ssh directory, with the correct permissions, if it doesn’t exist. In the next if block, the grep command’s output and error messages are suppressed. If the file exists but does not contain the key, the key is appended. If the file does not exist, the file is created and the key added. The chmod sets the proper permissions (owner read/write, all others: no access), just in case it’s not properly set.
So the AppleScript call would look something like this (untested):
do shell script "if test ! -d .ssh; then mkdir -m 700 .ssh; fi; if grep -q " & quoted form of theNewKey & " 2> /dev/null; then; else echo " & quoted form of theNewKey & " >> .ssh/authorized_keys ; fi && chmod 600 .ssh/authorized_keys"
(Where theNewKey is an AppleScript variable containing the plaintext public key.)
Yes, i am aware of your other post and have been contributing to it. I will ask here what i asked there: What is it you’re trying to do? There may be an easier way. If it’s merely to invoke an AppleScript, then we’ve already covered that, but if it’s something like sync files, then the UNIX tool rsync should be used. Or if it’s merely to inovke a script from time-to-time, then maybe you should be using cron.
How would this be easier with Linux? It’s a UNIX-like OS, and MacOS X is UNIX. Just about anything you could do in Linux should pretty much be doable in MacOS X.
I’ll attribute the Windoze remark as sheer frustration and won’t hold it against you, 
but saying things like that in this neighborhood can roasted at the stake!
And I appreciate all who have done so. I guess it must be me missing something very basic. This quesiton and the other (attempt to work around this problem) going so many pages of posts is just ludicrous and embarassing.
It seems like I’m trying to control the next shuttle mission via applescript.
I have written a script to perform a database cold backup, which will eventually be triggered based on time of day. However, there is a client connected to the database, on another server, that must shutdown before the backup can proceed. It then has to be restarted after the backkup is complete. There are scripts on the other server that handle gracefully shutting down and restarting the client. What I am trying to do is trigger those scripts from the backup script on the database server.
Just to refocus, the primary problem is the inability to authenticate to the client’s machine in spite of using the correct username and password. the other question involves useing ‘ssh,’ which works fine for authentication but has a problem with spaces in the folder names. But that is a workaround and not the desired method. I will probably abandon that question since it is also turning out to be just as troublesome.
- The client would not be insisting on Applescript.
- It already works and without the added layer of Applescript there would not be a problem with the spaces in the folder names.
Its the key words, “just about”, “should”, and “pretty much” that are the kickers. If only that were true, I guess I wouldn’t need to be here.
One of the benefits of being anonymous is that I can extol the virtues of windows all day in a Mac forum and the worse that can happen is I’ll get booted from the list (well, OK, maybe my nose will grow too). :twisted:
Okay, well that certainly clarifies things a bit. Not having used AppleScript on a remote machine, i obviously can’t help you troubleshoot that one. But i can help you with the workaround. And you’re right, it should be much easier than you’re experiencing.
First, regarding the matter of the space in the pathname, which seems to be the stumbling block for you in the ssh solution: You could always locate the script (or a UNIX link to it, or a Macintosh alias to it) anyplace you like; it need not go into a path containing a space. But assuming that, for whatever reason you don’t want to do it that way, here’s how you go about solving the problem:
As Greg has already noted, it is wisest to first get the command working from the Terminal before constructing your do shell script command. Once you have done this, then construct a string which you can plug into an AppleScript display dialog and will display the exact string you entered from the terminal (this ensures your quoting, etc. is correct). When that is correct, change the display dialog command to a do shell script command and it should work.
Here’s an AppleScript you might run on the target (i.e. remote) machine:
set theFilepath to POSIX path of (choose file)
set theCommand to "osascript " & quoted form of theFilepath
do shell script theCommand
set sshCommand to "ssh userID@server "" & theCommand & """
display dialog sshCommand
return sshCommand
First you choose the script you want to execute on that machine using a standard Macintosh GUI dialog, then it should run the script. Afterward it will display a dialog with an ssh command you should be able to use to remotely access the selected script (assuming you select appropriate values for userID@server), and it will return that string in the result (which will look somewhat different from that in the dialog, due to quoting). Drop that result into a do shell script in your controlling AppleScript to invoke the ssh session.
So there you have about three different ways to go about this problem.