Re: Osascript and ssh
Re: Osascript and ssh
- Subject: Re: Osascript and ssh
- From: Axel Luttgens <email@hidden>
- Date: Fri, 30 Apr 2004 12:32:35 +0200
Nigel Smith wrote:
On 29/4/04 10:15, "Axel Luttgens" <email@hidden> wrote:
Just a guess.
Does your calling script really need to run as nobody?
OK. We need some background, something I was trying to avoid boring the list
with *before* I had a solution :-)
Don't know if you really would have bored the list; after all, we all
are just curious guys ;-)
Anyway, many thanks for your patience, as I finally understood what you
really wanted.
Well, I believe I have...
So, yes, in the context you are considering, your initial process is
(has to be) running as nobody.
And you are considering to use that process to start a ssh session
locally (I initially understood that you were considering a remote
connection, and that confused me very much with regards of other parts
of your posts).
[...]
One way round this is ssh to localhost, using the account of a logged-in GUI
user, hence user "nobody" sending the command when user "nigel" is logged
in:
ssh nigel@127.0.0.1 "osascript -e 'do stuff'"
Only useful if there is some way to also script in the password stage.
For that very precise question, the only way I can think of is to use
expect, that comes bundled since 10.3.
Perhaps that will do it.
Well, it should. As a "proof" of the concept:
echo -n 'spawn ssh nigel@127.0.0.1 "sleep 10" ; expect "(yes/no)?" ;
send yes\r ; expect "password:" ; send nigelspass\r ; expect eof ' |
expect -d -
That quick and very dirty one-liner is to be used as the command line in
a xgrid shell job.
Of course, this would require the password to be stored somewhere in clear.
Or passed as one of the parameters of the Xgrid job (later versions of Xgrid
may use SSL to pass jobs around).I also envisage the GUI account used to be
limited using standard OSX security features such as "Limitations" in the
"Accounts" control panel, locked screen, etc.
Another way of doing all this, rather than using ssh/osascript, would be to
use Remote Apple Events. I was avoiding this because I find Photoshop to be
unscriptable over eppc://.
I really don't have any idea about scripting Photoshop.
Do you mean that it has a valuable scripting model but that its remote
scriptability is broken?
Just out of curiosity, what kind of limitations do you encounter with
Photoshop and eppc://?
But I've had another idea -- a stay-open script
application which listens for Remote Apple Events and passes them on to the
local Photoshop. I'll try this later.
I'm not sure, but I tend to believe it would be a better way for
launching and controlling Photoshop on multiple computers than going
through xgrid.
Not sure whether the latter really is the right tool for what you
consider (after all, it is intended for distributed computing, not
really for remote control).
Moreover, with eppc:// or a stay-open, you would have a universal
solution (who knows what xgrid's future availability/support will be?).
[...]
Hope that explains things better,
Yes! Yes! It did!
Axel
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.