In the lines below, the code after the #=> shows the results when executing the script. Follow the code to see several examples of a string using operations that are typically reserved for files.

require 'stringio'
str = StringIO.new %{This is a test of a string as a file. \r\n
                     And this could be another line in the file}

# Get a line
str.gets # => "This is a test of a string as a file. \r\n"

# Get the next 18 charaters
str.read(18) # => " And this could be"

# Seek to new position and read 7 more characters
str.pos = 59  # => 59
str.read(7) # => "another"

# Rewind the file and overwrite some of the existing text
str.rewind
str.write("Here's how to use")

# Rewind again and output the new contents
str.rewind
str.read # => "Here's how to use a string as a file.
     \r\n And this could be another line in the file"
str.eof? # => true

Any easy way to work with a string in a method that is expecting a file is to create a new StringIO object and pass the result to the method requiring a file type. For example:

  some_method(StringIO.new("Your string here"))

We can work around this by creating a simple Stack class as follows:

class Stack

  def initialize
   @the_stack = []
  end

  def push(item)
    @the_stack.push item
  end

  def pop
    @the_stack.pop
  end

  def count
    @the_stack.length
  end
end

Here is how you might use the stack:

  stack = Stack.new
  stack.push('abc')
  stack.push(100)
  stack.count
  stack.pop()

If need be, you could also add a few convenience methods such as clearing the stack or looking at the last element (without popping it off the stack):

  def clear
    @the_stack.clear
  end

  def look
    @the_stack.last
  end

Give this a try if you need to work with an array as a stack and want to play within the rules of how a stack is implemented as a traditional data structure.

I would recommend you verify the path to the Ruby interpreter within the ASDictionary preference settings. To determine the location of the Ruby interpreter on your system, enter which ruby in a terminal:

Copy the path (where Ruby is located on your system) into the Preferences dialog for ASDictionary as shown below. That should do it for configuration.

The best way to understand how the interactive help works is to go through an example. So, let’s say that you are interested to get the name of every item in the Documents folder…begin by starting the Ruby interactive interpreter , following by the necessary require/include statements (see below) and creating a reference to the Finder application. From Finder, we can make our first request for help, by invoking Finder.help:

Notice there is a property (highlighted above) for a home property, which provides a shortcut to the user’s Home folder. Taking this one step further, let’s request additional help entering Finder.home.help:

Under the list of Elements, notice the reference to folders, which indicates that a folder object has a one-to-many relationship with the file system objects it contains. Using this information, you could now access all the sub-folders of the home folder using the folders element.

Appscript uses the #[] method to specify elements by name, so to get the Documents folder of the Home folder you could use: finder.home.folders['Documents']. Referring again to the help information, we know that we can get the contents (items) of a folder using the items element. Using items will identify all of the folder’s contents. Notice the other options such as files, alias_files, application_files, etc that we can use to identify only certain types of items within a folder.

We can further drill down with the help system to get more information about the items within a folder using finder.home.folders['Documents'].items.help, as shown below:

Notice we can now access an items name, extension, among other properties. We began with the intention to get the name of every item in the Document folders, and with the last help statement, we now have all the information we need. The full rb-appscript statement looks like this: finder.home.folders['Documents'].items.name.get

You can read more about the help system in the rb-appscript manual.

Additional posts in the series: Part 1, Part 2, Part 3, Part 4, Part 5

The Open Scripting Architecture (OSA) is designed to allow for automating tasks, inter-application communication and otherwise directing application behavior. Apple events are the backbone of OSA, facilitating messaging and interaction with applications (think interprocess communication).

The structure of an application or a document is defined through the Apple event object model. When an application implements this object model, that application is then considered scriptable, which means you can communicate with the application using AppleScript, rb-appscript or other scripting languages that are OSA compliant.

In regards to the object model, elements refer to attributes such as the paragraphs or words of a document. Elements can be referred to by numerical position or, if they have ‘name’ properties, by name. Objects also have properties, which can hold either a simple attribute (name, position, etc.), or a reference to another application object. An important distinction is that there can be any number of elements (e.g. paragraphs, words, etc) whereas a property has only one defined value (e.g. version number).

The figure below shows the relationships of elements and properties and is from the paper The Open Scripting Architecture: Automating, Integrating, and Customizing Application by Cook and Harris, 1993.
.

As an example of a property that includes a reference to another object, the text property of the TextEdit application contains a text object, which includes character, word and paragraph elements. Each of these elements can be accessed using various commands as shown in the examples below:

# Set text color
tedit = app('TextEdit')
tedit.documents[1].text.paragraphs.color.set('blue')

# New paragraph at the end of the document
tedit.make(:new => :paragraph,
                :with_data =>
                "New content here...", :at =>
                tedit.documents[1].text.paragraphs.end)

Using commands we can interact with objects using rb-appscript. Applications generally support the commands: run, launch, activate, reopen, open, print and quit. Depending on the application, there may be any number of additional commands that are available. For example, TextEdit offers the ‘make’ command (shown above) that can be used to make a new paragraph, create a new document, etc.

Let’s wrap up by showing a few examples. Enter the following commands using irb :

#1 Begin by importing the appscript module:
require "appscript"
include Appscript

#2 - Create an new object specifying the application we want to target
tedit = app('TextEdit')

#3 - Create a new document using make command:
doc = tedit.make(:new => :document)

#4 - Set the content of the document:
tedit.set(doc.text, :to => 'First paragraph')

#5 - Set text color
tedit.documents[1].text.paragraphs.color.set('blue')

#6 - Get the document text
text = tedit.get(doc.text)

#7 - Show text
puts text

The TextEdit document should look as follows when you are done:

Hopefully this post has provided a little more insight as to the object model and working with elements, properties and commands. In the next post I’ll show how to use the interactive help built into rb-appscript.

Additional posts in the series: Part 1, Part 2, Part 3, Part 4, Part 6

require 'irb/completion'
require 'irb/ext/save-history'

ARGV.concat [ "--readline",
              "--prompt-mode",
              "simple" ]

# 25 entries in the list
IRB.conf[:SAVE_HISTORY] = 25

# Store results in home directory with specified file name
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-history"

The reference to SAVE_HISTORY is how many commands you want to store in the history list and the HISTORY_FILE is the name of the file where the commands are stored. Save the file as ~/.irbrc (in your home directory with the name .irbrc).

Below I’ve enter several commands using irb. I used command completion (hitting tab key twice) on the line that begins with “a.p” and you can see how command completion shows the available options (a.pack, a.parition, etc).

Once I quite the irb session and open the .irb_history file it will look as follows:

Now, if I start a new irb session the commands in the history file be available by pressing the up arrow (not unlike the history available in a Terminal window). Although this configuration option is nothing new for those who been working with Ruby, it warrants mentioning for anyone who is just getting started with Ruby.

The AppleScript example we are porting to Ruby is as follows:

tell application "Finder"

display dialog "What would you like to do?"
   buttons {"Shutdown", "Restart", "Cancel"} default button "Cancel"
  with icon caution

if button returned is "Shutdown" then
  set volume 0
  shut down
else if button returned is "Restart" then
  set volume 0
  restart
end if

end tell

Pretty simple application, display a dialog box with three options and based on the selected option, shut down the system, go to sleep or do nothing. The application to reset the volume at boot time is all of one line:

set volume 5

You can get the specifics of how I used these scripts by referring back to the original post.

The Ruby version of the first script looks as follows:

require 'osax'
include OSAX

# Display dialog box and get user request
dialog = osax.display_dialog( "What would you like to do?",
  :buttons => ["Shutdown", "Restart", "Cancel "], :default_button => "Cancel ",
  :with_title => "System Shutdown...", :with_icon => :caution)

if dialog[:button_returned] == "Shutdown"
  puts "Shutdown"
  osax.set_volume(0)
  app("System Events").shut_down()
elsif dialog[:button_returned] == "Restart"
  puts "Restart"
  osax.set_volume(0)
  app("System Events").restart()
end

The Ruby code to reset the volume is as simple as its AppleScript counterpart:

require 'osax'
include OSAX

# Turn volume up (range is 0 to 7)
osax.set_volume(5)

One caveat worth mentioning regarding the Ruby code: notice there is space in the references to “Cancel ” – You can read why that is by following this thread on the rb-appscript discussion/mailing list.

Additional Resources:

I’ll leave you with a few additional resources that should be helpful if you are new to rb-appscript and/or AppleScript:

• Documentation on rb-appscript
• Tutorial on getting started with rb-appscript
• Additional links

Additional posts in the series: Part 1, Part 2, Part 3, Part 5, Part 6

require 'osax'
include OSAX

# List available scripting additions
puts osax.scripting_additions

puts "~~~~~~~~~~"

# List all commands:
puts osax.commands

Notice the third line from the top, StandardAdditions, this is the addition I’m after. Let’s take this one step further and view the rb-appscript variation of a dictionary. rb-appscript includes a tool, ASDictionary, which will export to text or HTML (I recommend the HTML with frames option) information on scriptable applications.

Not unlike the dictionary available in the Script Editor, ASDictionary will list the suites, classes and commands, however, the content is tailored for use with specifically with rb-appscript and Ruby. The screenshot below shows the StandardAdditions library information from with ASDictionary.

Now, contrast the above image with the image below, which is the Standard Additions dictionary shown yesterday (for AppleScript).

When working with rb-appscript, you’ll notice how what would be accessed with AppleScipt as display dialog is requested using display_dialog(…) in rb-appscript.

As a more complete example, the code below will show a dialog box using AppleScript:

display dialog "What would you like to do?" buttons {"Shutdown", "Restart", "Cancel"}
   default button "Shutdown" with icon caution

Here is the same code written using Ruby:

osax.display_dialog( "What would you like to do?", :buttons => [ "Shutdown", "Restart", "Cancel " ],
  :default_button => "Shutdown", :with_icon => :caution)

Regardless of the approach, the end result of the either code block above looks the same:

This is a good time to point you at the documentation for rb-appscript as it covers in great detail all the specifics.

At this point I’ve covered enough to write something useful. Have a look at the following AppleScript code that I wrote about in a previous post.

tell application "Finder"

display dialog "What would you like to do?"
   buttons {"Shutdown", "Restart", "Cancel"} default button "Shutdown"
  with icon caution

if button returned is "Shutdown" then
  set volume 0
  shut down
else if button returned is "Restart" then
  set volume 0
  restart
end if

end tell

In an upcoming post I’ll show to write the same script using using Ruby and rb-appscript. I realize this is a pretty short example, however, if nothing else it should help pull all the pieces together into a working Ruby application that offers an alternative to AppleScript.

Additional posts in the series: Part 1, Part 2, Part 4, Part 5, Part 6

My intention in exploring an alternative was to find an option for scripting beyond AppleScript itself and to rewrite an AppleScript program that I was currently using. The original AppleScript code was written to turn down the volume upon shutdown, to enable a silent bootup process. You can read the who, what and why in the original post.

However, I’m getting ahead of myself. Before we dig into the original code and how to write the same application in Ruby, let me take some time to explain a few other things important concepts within AppleScript.

Dictionaries

In order to work with a scriptable application (or aspects of the system that are scriptable), one first needs to know what is scritable and how to interact with the scriptable resource, an API of sorts. In AppleScript parlance this is know as the Apple event registry, also referred to as a dictionary.

Let’s look at a few examples – to open the dictionary for system related events, open the Script Editor, click on File / Open Dictionary, and browse to the “System Events.app” application. Scroll down to the Power Suite and you should see a listing similar to the Figure below, which shows information on the commands: logout, restart, shutdown and sleep.

Information is organized into suites, which are shown in the leftmost window. In the middle column are available commands for the Power Suite. There is a great deal more information available within the dictionary, however, I’ll save the detailed description for another day.

Scripting Additions

Scripting Additions are a mechanism for extending the functionality of AppleScript. There are any number of Scripting Additions available (google for scripting additions) from mathematical stuff to sending SMS messages. A good list of addtions can be found at osaxen.com.

A commonly used Scripting Addition, and one which is included by default, is Standard Additions. For example, to display a dialog box, you use the User Interaction Suite and the display dialog command as shown in the figure below. To bring up this dictionary from within the Script Editor, open a new dictionary and scroll to the Standard Additions entry.

The information covered up to this point will lead us to the next post, which will make it clear why I chose the dictionaries I did in the examples above. And with the next post we’ll begin to dig into some Ruby code to make a few things happen with Apple Events. Same bat time, same bat channel…

Additional posts in the series: Part 1, Part 3, Part 4, Part 5, Part 6

Here is the description of AppleScript from the Apple website:

AppleScript is an English-like language used to create script files that control the actions of the computer and the applications that run on it. Much more than just a macro-language, which simply repeats your recorded actions, AppleScript scripts can “think.”

If you come from a programming background, it may take some time to get used to the “English-like” interface. Now this is not necessarily a bad thing as it makes AppleScript more approachable for those without any experience writing code.

In my search for an alternative to AppleScript, I came upon rb-appscript. Ruby appscript is an Apple event bridge that provides a framework for querying and controlling scriptable applications from Ruby. I first read about rb-appscript in this article at O’Reilly, which provides an excellent introduction to the topic.

Let’s walk through how to install rb-appscript and wrap up with a short Ruby script to verify everything is working. For installation, there are two options – one is via RubyGems, the second is to build from source. I generally build from source as I have more control over the process. The steps for doing so are shown below (you’ll find the same basic steps listed in the O’Reilly article mentioned above):

1. Download rb-appscript from RubyForge (I am running rb-appscript-0.5.1)
2. Extract the contents of the zip file
3. From the directory where the files were extracted, run these commands from a Terminal:

> ruby extconf.rb
> make
> sudo make install

4. Open a text file and enter the following code:

require "appscript"
include Appscript

app('TextEdit').activate

5. Save the file as test.rb and from a Terminal run the script:
   > ruby test.rb

This short application does nothing more then use an application object to activate TextEdit, bringing it to the foreground (starting it if necessary). If all is well, you should see TextEdit as the top most application.

In the next tip I’ll dig a little deeper into working with rb-appscript, including a look at how to access Standard Additions such as dialog boxes.

Additional posts in the series: Part 2, Part 3, Part 4, Part 5, Part 6