Script Editor Click to paste code into the Script Editor

----------------------------------------
--  MacDeveloperTips.com
--  Toggle Finder hidden file status
----------------------------------------
try
  -- Get current value
  set toggle to do shell script "defaults read com.apple.finder AppleShowAllFiles"

  -- Toggle it
  if toggle = "ON" then
    do shell script "defaults write com.apple.finder AppleShowAllFiles OFF"
  else
    do shell script "defaults write com.apple.finder AppleShowAllFiles ON
  end if

  -- Restart Finder
  tell application "Finder" to quit
  delay 0.5 -- If you have problems, you can tweak the delay
  tell application "Finder" to launch
on error

  display dialog "Unable to toggle bit status." buttons {"Better luck next time"}
    with icon caution with title "Error"
end try

Notice the reference to delay – if you have problems with the scripting not running properly, you can experiment with a longer delay. There is minimal error handling, essentially just trapping errors and displaying the message below:

I prefer to save AppleScript code as an application, create an icon that serves as a reminder of what the script does, and drag/drop the application onto the Finder toolbar. You can see a screenshot below what my toolbar looks like (the icon for this script is the blue & white Finder image).

And speaking of icons, in an upcoming tip I’ll show you how easy it is to change an application icon on a Mac.

The gist of the application is to instruct iTunes to play a random song, move to the next song, pause, etc. I’ll show one use of the application by wrapping the code into a bash script that allows you to invoke the program (and all commands) from within a terminal. Watch the video that follows for all the details…

This application is all of about 80 lines, including the bash script. Sometimes a little creative thinking and a few lines of code are all that’s needed to write an intriguing (and hopefully useful) application.

There is a subtle difference, in the previous post the focus was on how to write code in Ruby (inside NetBeans) using the rb-appscript bridge. This time around the approach is to work with Java and pass AppleScript code to a set of Cocoa files (classes) that will act as the bridge between our application and the Mac system.

There is one caveat – the Cocoa-Java API is deprecated as of Mac OS X Tiger. The NSAppleScript and NSMutableDictionary classes are still available, however, they are no longer on the development path within Apple. There are scripting bridges that allow you to control scriptable applications using Python, Ruby, and Objective-C. Java Native Interface (JNI) is an additional option to call platform specific code. You can read more about JNI in this technical note: JNI development on Mac OS X.

One more note, if you follow the steps in this video and the classes NSAppleScript and NSMutableDictionary are shown with lines through them (for example, NSAppleScript), this has to do with a preference setting inside NetBeans to show deprecated classes with a strike-through. You can change this as follows: From the Preferences dialog, choose Fonts/Colors; click the Syntax option; from the Language list choose Java; click on Deprecated Element; in the Effects option, choose None.

Join me in Part 2 of this tip where I’ll show a more comprehensive (read: interesting) example where it’s all about controlling iTunes using Java.

For instance, when you need to select files with a unique patterns such as: files that contain the string “test” (anywhere within the filename), or only those files where the name contains “test” and the extension is “rb”.

The application I am referring to is lselect, and here are a few examples:

All files with “test” in the name and the extension “rb” will be selected:

Easy enough, however, lselect also allows you to add to the current list of selected files, as shown below where I ask for all files with a “C” extension (notice the button ‘Add Matches’):

The resulting list of files is shown below:

The source code for lselect is shown below (it looks rather long, however, much of the listing is comment blocks):

Click here to paste the code below into the Script Editor

(*
  lselect 1.1 by Jim DeVona

http://anoved.net/lselect.html

  1.0: 1 November 2006
  1.1: 18 December 2006 (somewhat improved Column view behavior)

  Select files in the current Finder folder using shell glob syntax.
  When invoked, the user will be prompted to supply a glob pattern.
  The "ls" command line utility is used to determine which files match
  the pattern, and then they are selected.

  Suggested installation location:
    ~/Library/Scripts/Applications/Finder/lselect.scpt

  The script can be invoked with the standard Mac OS X Script Menu,
  but I've found FastScripts (http://www.red-sweater.com/fastscripts/)
  to be a preferable alternative, primarily because of the ease with
  which reliable keyboard bindings can be assigned. I use Command-G.

  Issues:
    - If the last match is a directory and the current view type is
      Column, other matches will not end up selected (they appear
      to lose selection when the Finder come to rest on and reveals the
      contents of the last directory). I don't know how to prevent this.
    - Spaces must be escaped to match properly: "iTunes\ Music"
    - Performance is poor with hundreds of matches; see notes below

  Wishes:
    - Select sub-matches within current selection
    - Select matches on desktop instead of in "Desktop" window
    - Support patterns like "../" (subfolder patterns work, but not parent)
*)

tell application "Finder"

  (*
    Determine the present working directory as alias and POSIX path.
    If the insertion location is not a folder, use its parent. This is the
    case when a file is selected in Column view (otherwise, file selections
    do not seem to be treated as the insertion location).
  *)
  set pwdAlias to insertion location as alias
  if not (exists folder pwdAlias) then
    set pwdAlias to (container of pwdAlias) as alias
  end if
  set pwd to POSIX path of pwdAlias

  (*
    Ask the user what to select. Dialog time out is equivalent to cancellation.
    The default "Select Matches" option clears the current Finder selection,
    whereas "Add Matches" leaves it intact. Clearing the selection is not done
    in Column view if the displayed folder is the only thing selected.
  *)
  set dr to display dialog "Glob pattern:" default answer ¬
    "" buttons {"Cancel", "Add Matches", "Select Matches"} ¬
    default button 3 cancel button 1 with title pwd giving up after 60
  if button returned of dr is equal to "" then
    return
  else if button returned of dr is equal to "Select Matches" then
    try
      -- do not clear selection if the only thing selected is the focal folder
      if selection as alias is not equal to pwdAlias then select {}
    on error
      -- more than one thing already selected
      select {}
    end try
  end if

  (*
    Initialize list of selected files. Generally identical to selection returned
    by Finder, except the present working directory should not be included,
    which is initially selected in some Column view circumstances (see above).
    This is a little clumsy; selection state is vaguely defined in Column view.
  *)
  set selectables to selection
  try
    if selection as alias is equal to pwdAlias then set selectables to {}
  end try

  (*
    Get the glob pattern given by the user.
    We treat a blank pattern as cancellation (use * to select everything).
    Alternatively, omit this conditional to select the containing folder;
    this ought to be the default behavior once "../" issues are ironed out.
  *)
  set query to text returned of dr
  if query = "" then return

  (*
    Ask ls for a listing of files that match the given pattern.
    From the ls man page:
      -d Directories are listed as plain files (not searched recursively).
    If nothing matches the query, ls will return an error; just stop.
  *)
  try
    tell me to set matches to do shell script ("/bin/ls -d " & quoted form of pwd & query)
  on error
    return
  end try

  (*
    Parse each line of the response from ls as the path to a match.
    The visibility test is twofold: the "info for" test throws an error on
    Icon^M (the full name doesn't survive all translations and transmissions).
    This try-info-for-visibilty test is the main bottleneck;
    for faster handling of many matches (100s), replace this
    repeat body with "set end of selectables to matchpath as POSIX file"
  *)
  repeat with matchpath in paragraphs of matches
    set posixmatch to matchpath as POSIX file
    try
      set fileinfo to info for posixmatch without size
      if visible of fileinfo then set end of selectables to posixmatch
    end try
  end repeat

  (*
    Conclude by selecting the results.
    The "try" protects against cases we don't [yet] handle,
    such as certain "../" path traversals and anything else that may come up.
    If the last item of selectables is a directory and we're using
    Column view, other items may not end up selected.
  *)
  try
    select every item of selectables
  on error errMsg number errNum
    display alert "Could not make selection (" & errNum & "):" message errMsg as critical
    return
  end try
end tell

Here is brief list of glob syntax you can try with lselect:

? Match any one character.
* Match any sequence of zero or more characters.
[abc] Match any one character in abc. A range of characters may be specified as a-z, or 0-9.
[^abc] Match any one character not in abc.
{a,b,c} Matches any of the strings a, b, or c, which may consist of more than one character each.

lselect shows a good use of AppleScript, is well documented and it’s handy…all good things.

In this post I’ll describe more about how all these tools come together to provide an interesting approach for using Ruby as an alternative to AppleScript, and working with NetBeans as the development environment for writing and building those same applications.

The screencast that follows will walk you through all the steps to download the tools you’ll need, build from source a scripting bridge (rb-appscript) for Ruby to AppleScript, and finally, create several short examples to demonstrate how you can use Ruby, from within NetBeans to control scriptable applications.

For more information, follow these links:

• NetBeans
• rb-appscript
• AppleScript

If you are interested to learn more about using Ruby as an alternative to AppleScript, I’ve written as series of posts you can find here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6

If you write an interesting application in NetBeans, using Ruby and rb-appscript, drop me a note, as I’d like to post several good examples showing the interaction of all these tools.

As an aside, NetBeans is sponsoring a blogging contest for the 6.1 Beta. If you are interested in learning more, visit the NetBeans Blogging Contest. And who knows, you could walk away with one of ten $500 American Express gift certificates!

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

With the release of AppleScript 2.0 (accompanying Leopard) there is now support for Unicode, so you can do things like this:

The application object has updates as well, such that you can check whether an application is running, is it the front-most application, what version is running, etc. There are also additions to scripting support across the system, for instance, network preferences are now scriptable. You can find all the release notes for 2.0 here.

If you are new to AppleScript, there is an AppleScript Fundamentals section that offers a good high-level overview of AppleScript from Objects to Scripting Additions to Commands, among other topics. On that same line of thought, you may also want to spend some time poking around the debugging tips which includes an updated section on handling of errors with try statements and error statements.

You can download a PDF version of the file that is handy if you’d like to print a copy.