Automating OS X with Ruby.

[Stephen Schor]

[Note: parts of this message were removed to make it a legal post.]

Howdy,

I just upgraded to leopard and thought it would be a good opportunity to
learn automation in OS X.
I started playing around with Ruby OSA (http://rubyosa.rubyforge.org/).
Many of the 'hello world' applications
look something like:

require 'rbosa'
itunes = OSA.app('iTunes')

track = itunes.current_track
puts track.name # "Over The Rainbow"


However - I can't interact with the *itunes* object unless I manually open
the application.
After I manually open it - I can call nifty methods like itunes.play() and
itunes.stop().
I tried calling itunes.open() but that wouldn't launch the application.
After combing over RDocs and the Ruby OSA mailing list - I didn't see
anything too helpful.

Does anyone have experience with the Ruby OSA library? Do you have a
different, favorite way to automate OS X?
What sites do you find most helpful in learning about OS X automation?

-Stephen

 

[Giles Bowkett]

require 'rbosa'

itunes = OSA.app('iTunes')

track = itunes.current_track
puts track.name # "Over The Rainbow"


However - I can't interact with the *itunes* object unless I manually open
the application.
After I manually open it - I can call nifty methods like itunes.play() and
itunes.stop().
I tried calling itunes.open() but that wouldn't launch the application.
After combing over RDocs and the Ruby OSA mailing list - I didn't see
anything too helpful.

Does anyone have experience with the Ruby OSA library? Do you have a
different, favorite way to automate OS X?
What sites do you find most helpful in learning about OS X automation?

There's an open system call on the bash command line in OS X, so what
I do in situations like that is

system("open xyz")

or

`open xyz`

It's the easy way out, but it works. I haven't played with OSA
scripting yet, but it *may* work perfectly if you just throw in a
sleep() call to let the app load once the open call's been made.

To get iTunes to open you'd want

system("open -a iTunes")

Brian Marick is writing a book about scripting OS X with Ruby, you
should hop on the mailing list for that.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[Ryan Davis]

However - I can't interact with the *itunes* object unless I
manually open
the application.
After I manually open it - I can call nifty methods like
itunes.play() and
itunes.stop().
I tried calling itunes.open() but that wouldn't launch the
application.

I dunno about rubyosa, but applescript uses 'activate'.

 

[Dane Jensen]

I dunno about rubyosa, but applescript uses 'activate'.

Indeed. itunes.activate will start it if it's not open.

 

[Stephen Schor]

[Note: parts of this message were removed to make it a legal post.]

Thanks for all the replies. Calling .activate() isn't working for me...but
opening it though the shell with
system("open -a 'itunes'") will work for now. Here's a snippet from the IRB
session:
RuntimeError: Cannot send Apple Event 'miscactv' : procNotFound
(-600)
from /Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:796:in
`__send_event__'
from /Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:796:in
`activate'

However - after a bit of searching I found what looks to be a related post
by *Laurent Sansonetti *in Rubyosa mailing list.
(http://mail.google.com/mail/?hl=en&tab=wm#inbox/1170f53ede402ae8) about why
calling OSA.app('blah') on certain applications won't
launch them.

-Stephen

 

[has]

Does anyone have experience with the Ruby OSA library?  

Used it; don't much like it. It lacks various features found in
AppleScript, has poorer application compatibility, and its attempts to
dress up Apple event IPC in object-oriented semantics create various
hidden gotchas.

The best currently available solution is rb-appscript - see my sig for
links. The recent 0.5.0 compares very well to AppleScript in terms of
power and reliability, and you get additional benefits such as a
powerful built-in help system. If you're coming from an OO background
you'll find Apple events' EPC+query-based behaviour a bit strange at
first, but you soon get used to it. See the appscript manual for some
background information and a tutorial to get you started.

What sites do you find most helpful in learning about OS X automation?

For now, you largely have to work with existing AppleScript-based
resources as there's not a lot of material out there on using other
languages in its place. (Hopefully this will improve as more folks
start using Python, Ruby, etc. as AppleScript replacements.) Here's a
recent thread that may be of some help:

http://groups.google.co.uk/group/comp.lang.ruby/browse_frm/thread/31f2bfa25cfad667/

HTH

has

 

[John Joyce]

Used it; don't much like it. It lacks various features found in
AppleScript, has poorer application compatibility, and its attempts to
dress up Apple event IPC in object-oriented semantics create various
hidden gotchas.

The best currently available solution is rb-appscript - see my sig for
links. The recent 0.5.0 compares very well to AppleScript in terms of
power and reliability, and you get additional benefits such as a
powerful built-in help system. If you're coming from an OO background
you'll find Apple events' EPC+query-based behaviour a bit strange at
first, but you soon get used to it. See the appscript manual for some
background information and a tutorial to get you started.



For now, you largely have to work with existing AppleScript-based
resources as there's not a lot of material out there on using other
languages in its place. (Hopefully this will improve as more folks
start using Python, Ruby, etc. as AppleScript replacements.) Here's a
recent thread that may be of some help:

http://groups.google.co.uk/group/comp.lang.ruby/browse_frm/thread/
31f2bfa25cfad667/

HTH

has

I'm going to second this opinion.
I tried the others, but rb-appscript is definitely more robust.

 

[Stephen Schor]

[Note: parts of this message were removed to make it a legal post.]

Sorry about the copy and paste error. Laurent Sansonetti's post can be
found here
(http://rubyforge.org/pipermail/rubyosa-discuss/2006-October.txt)
It's the message sent " Sat, 28 Oct 2006 23:37:25 +0200"...

"After a quick investigation it revealed that QuickTime Player.app
doesn't wake up when we request its scriptable definition, for the
reason that it uses the old aete mechanism and that the sdef is
generated on the fly, without the need to actually start and ask the
application. However from a RubyOSA perspective, we should probably
ensure that the given application is active after an OSA.app call"

 

[has]

[Note:  parts of this message were removed to make it a legal post.]

Sorry about the copy and paste error.  Laurent Sansonetti's post can be
found here
(http://rubyforge.org/pipermail/rubyosa-discuss/2006-October.txt)
It's the message sent " Sat, 28 Oct 2006 23:37:25 +0200"...

"After a quick investigation it revealed that QuickTime Player.app
doesn't wake up when we request its scriptable definition, for the
reason that it uses the old aete mechanism and that the sdef is
generated on the fly, without the need to actually start and ask the
application. However from a RubyOSA perspective, we should probably
ensure that the given application is active after an OSA.app call"

That's just sloppy design on RubyOSA's part, relying on a side-effect
of the terminology retrieval process that may or may not need to
launch an application depending on whether its terminology is
dynamically or statically defined.

AppleScript and appscript both do the sensible thing, which is to
launch a non-running application themselves via the Process Manager/
LaunchServices the first time they need to send it an event.

Again, I'd recommend Ruby appscript as the best choice for controlling
"AppleScriptable" Mac applications from Ruby (with Leopard's Scripting
Bridge a poor second if you absolutely can't have external
dependencies). Rb-appscript is based on the Python appscript bridge
which has been around since 2003, so it's a much more mature, polished
solution than RubyOSA and easily gives AppleScript a run for its money
too.

HTH

has