Platypus is a developer tool for the Mac OS X operating system. It can be used to create native, flawlessly integrated Mac OS X applications from interpreted scripts such as shell scripts or Perl, Ruby and Python programs. This is done by wrapping the script in an application bundle directory structure along with an executable binary that runs the script.

Platypus makes it easy for you to share your scripts and programs with those unfamiliar with the command line interface, without any knowledge of the Mac OS X APIs -- a few clicks and you will have your own Mac OS X graphical program. Creating installers, maintenance applications, login items, launchers, automations and droplets is very easy using Platypus.

Supports shell scripts, Perl, Python, PHP, Ruby, Expect, Tcl, AppleScript
Supports arbitrary interpreter specification
Executing scripts with root privileges via Apple's Security Framework
Drag and drop files or text snippets, which are then passed to the script as arguments
Can display graphical feedback of script execution as progress bar, text window with script output, WebKit HTML rendering or status item menus
Can create applications which run in the background (LSUIElement)
Sophisticated app bundle configuration for associated file types, identifier, version etc.
Graphical interface for bundling support files with script
Built-in script editor, or linking with external editor of choice
Set own application icon or select from presets
Command line tool for automating script application bundling
"Profiles" which can be used to save configurations

rb-appscript

### Description

In Mac OS X 10.3, Apple introduced a new scheme for identifying data types called [Uniform Type Identifiers][1].

One requirement that Mac OS X puts on any application that wants to use these identifiers is that it declare them in its Info.plist—not just in [CFBundleDocumentTypes][2] and [NSServices][3], but also in [UTImportedTypeDeclarations][4] and [UTExpertedTypeDeclarations][5]. Otherwise, Mac OS X 10.4 and later will ignore your application's uses of those UTIs elsewhere in your Info.plist.

This creates a lot of work for you, especially when importing a type declaration. Exporting a new declaration is easy, because it's your type: you can make up whatever you want. But to import a declaration, you must gather information about it and construct the dictionary yourself. This gets tedious, especially for some types (such as image types) that you may import in one application after another.

UTI Property List Helper is an application to solve this problem for you.

![The UTI Property List Helper window contains a table view, wherein you enter the UTIs, and two text views: one showing the CFBundleDocumentTypes array, and the other showing the UTImportedTypeDeclarations array.][6]


Simply add types to the list in the upper half of the window, and UTI Property List Helper will automatically update the two arrays in the lower half. When you're done, either select and copy each array's XML text into your Info.plist, or save it to a file.

### Mercurial repository

If you want to contribute bug-fixes or enhancements to UTIPropertyListHelper, the easiest way to do that is to clone [the Mercurial repository for UTIPropertyListHelper][7]. To do this, type this command into a terminal:

hg clone http://boredzo.org/uti-plist-helper/hg UTI-Plist-Helper

I provide UTIPlistHelper—the application, and its source code—under a three-clause BSD license. For more information, see the file named LICENSE.txt that comes with it.

[1]: http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/
[2]: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-101685
[3]: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-107265
[4]: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-114192
[5]: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-SW7
[6]: http://boredzo.org/UTI_Plist_Helper.png
[7]: http://boredzo.org/hg

The trap statement in bash causes your script to execute one or more commands when a signal is received. One of the useful things you can use this for is to clean up temporary files when your script exits.

To execute code when your script receives a signal, use the following syntax:

trap arg sigspec...
The "arg" is the command to execute. If the command contains spaces, quote it. You can include multiple commands by separating them with semicolons. For more complex things, put your exit code in a function and just invoke the function. The "sigspec" list is a list of signals to trap and then execute "arg" (if/when they occur). For example, to remove a file on EXIT, do the following:

trap "rm -f afile" EXIT
Note that EXIT is not a real signal (do kill -l to see all signals); it is synthesized by bash.

Be careful using wildcards in "arg", because if they are unquoted or quoted with double quotes, they get expanded when the trap statement is encountered and not when "arg" is executed. For example, if you have a file named "abc.tmp" and the following trap statement is executed:

trap "rm -f *.tmp" EXIT
the command that gets executed when the script exits is "rm -f abc.tmp" and not "rm -f *.tmp". To avoid this problem, use single quotes.

If you create temporary files at various places in your code and you don't use a naming convention that would allow you to use a wild card in your trap statement and you don't want to worry about changing your trap statement as your code evolves, you could write something like this to allow you to add new trap commands that get executed on exit:

#!/bin/bash

declare -a on_exit_items

function on_exit()
{
for i in "${on_exit_items[@]}"
do
echo "on_exit: $i"
eval $i
done
}

function add_on_exit()
{
local n=${#on_exit_items[*]}
on_exit_items[$n]="$*"
if [[ $n -eq 0 ]]; then
echo "Setting trap"
trap on_exit EXIT
fi
}

touch $$-1.tmp
add_on_exit rm -f $$-1.tmp

touch $$-2.tmp
add_on_exit rm -f $$-2.tmp

ls -la
Here the function add_on_exit() adds commands to an array, and the on_exit() function loops through the commands in the array and executes them on exit. The on_exit function gets set as the trap command the first time add_on_exit is called.

using terms from application "Quicksilver"
     on open thefiles
          repeat with afile in thefiles
               set afile to afile as text
               tell application "VLC"
                    activate
                    OpenURL afile
                    play
                    fullscreen
               end tell
          end repeat
     end open
end using terms from

find ~ -name '* *' | while read FILE
do
echo $FILE rocks.
done

•
Home
Features
•
Learn
Explore
•
Launch Scripts from Webpage Links
AppleScript applications can interact with websites displayed on your computer to perform tasks and display information. This is done through the process of the AppleScript application registering itself with the OS as the handler of specific URL protocols and schemes.

The following describes how to create your own helper script applications.

THE INFO.PLIST FILE

When you save the script as an application bundle, it will contain the standard Mac OS X bundle elements including an XML property list file defining important aspects of the script application.

To access the Info.plist property list, click on the script application with the Control key held down to access the Finder Contextual Menu. Choose Show Package Contents from this menu to open the script application bundle in a new window. Open the Contents folder within the new window to reveal the Info.plist file. Open this file in a text or property list editor and add the following XML keys and values to the property list.

To identify the Application, add the following lines to the property list, replacing the blue placeholder text shown here with a unique bundle identifier for your application:

<key>CFBundleIdentifier</key>
<string>com.apple.AppleScript.WebpageHelper</string>
To identify the URL handler that triggers the applet, add the following item to the property list, replacing the blue text with title of your URL protocol and the URL scheme of your protocol:

<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>Webpage Helper</string>
<key>CFBundleURLSchemes</key>
<array>
<string>webpagehelper</string>
</array>
</dict>
</array>

“I ran into an issue with Automator workflows that call unix shell scripts. I’ve detailed it here, but it boils down to if you have a workflow that sends filenames to the unix script, you need to add an extra Applescript step to sanitize the file names.
Just put a Run Applescript action ahead of the Run Shell Script action, and put the below code in. It’ll take the list of file aliases and convert them to properly quoted paths for the shell script to act on.”
on run {input, parameters}
set output to {}
repeat with i from 1 to length of input
set x to item i of input
set output to output & {quoted form of POSIX path of x}
end repeat
return output
end run

“To store references, use the Copy to Clipboard action from System Library. Place this after the results you need to store. Then to call it up, place a Run AppleScript action in the workflow with the following scriptlet before the action that needs the data from earlier in the workflow:
--Return Clipboard Contents to Data Flow
return (the clipboard)
This takes the information stored on the clipboard and puts it back in the Data Flow.”

Read/Write Property Lists
Prior to Mac OS X v10.5, property lists could only be read using the related suites in the System Events application. In Leopard, property list files can be created and edited. Here's a script example of how to create and populate a property list file:

An example script demonstrating how to create an new property list file:
 

tell application "System Events"
 -- create an empty property list dictionary item
 set the parent_dictionary to make new property list item with properties {kind:record}
 -- create new property list file using the empty dictionary list item as contents
 set the plistfile_path to "~/Desktop/example.plist"
 set this_plistfile to ¬
 make new property list file with properties {contents:parent_dictionary, name:plistfile_path}
 -- add new property list items of each of the supported types
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:boolean, name:"booleanKey", value:true}
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:date, name:"dateKey", value:current date}
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:list, name:"listKey"}
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:number, name:"numberKey", value:5}
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:record, name:"recordKey"}
 make new property list item at end of property list items of contents of this_plistfile ¬
 with properties {kind:string, name:"stringKey", value:"string value"}
end tell

The resulting XML of the newly created property list will look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>booleanKey</key>
<true/>
<key>dateKey</key>
<date>2007-08-07T22:09:04Z</date>
<key>listKey</key>
<array/>
<key>numberKey</key>
<integer>5</integer>
<key>recordKey</key>
<dict/>
<key>stringKey</key>
<string>string value</string>
</dict>
</plist>

Building An AppleScript-Based Automator Action

by Benjamin S. Waldie

There has been a lot of excitement in the developer community around the release of Mac OS X 10.4. Unique technologies like Automator, Dashboard, and Spotlight are providing new opportunities for Mac developers to build unique tools that appeal to users everywhere. This month, we are going to walk through the process of developing for one of these great new technologies, Automator.

Automator is Apple's new technology that is helping users everywhere to begin automating repetitive and time consuming tasks in their own unique workflows, allowing them to become more efficient. By placing actions, which are single automated tasks, together in a sequence, users are able to construct a fully automated workflow, without the need to write a single line of code. How does this help us, as developers, you may be asking? Well, someone needs to create the actions that give users this power.

Automator actions are built in Xcode, and are typically developed using either Objective-C, AppleScript, or a combination of these, and possibly other languages. Objective-C may be used to develop actions that interact with core components of the OS, or applications with a public API. AppleScript may be used to develop actions that interact with any scriptable application or process on the Mac.

In this article, we will walk through the process of creating a basic Automator action with AppleScript. This brief overview should provide you with a basic understanding of the primary steps involved in creating a simple AppleScript-based action. Once you understand the basic concepts of building an action, then you can take additional steps on your own to begin expanding your knowledge through additional resources. Before long, you will be creating complex actions that interact with a variety of scriptable applications or processes, and sharing those actions with users. Obviously, it should go without saying that you will need Mac OS X 10.4 and Xcode 2 or higher to create an Automator action.

Introduction to Database Events

by Benjamin S. Waldie

Data storage and access is an important part of AppleScripting, particularly in complex AppleScript-based projects. Some scripts may need to store user-entered data for later reference, perhaps during an entirely new session. Some may need a location to log activity or errors during processing. Others may need to access structured data, in order to do something fairly complex, such as building a catalog.

In this month's column, we will discuss the use of Database Events, a new and exciting feature in Mac OS X, for storage and access of data during script execution.

#!/bin/bash # # Creates a list of all files in all Simpsons folders and then # plays so many random episodes with VLC Media Player. # Created by Uncertain # Filenames and paths. path1=/home/zero/Videos/ path2=/home/zero/Videos/Simpsons list=/home/zero/Videos/Simpsons/episodes.txt # Check for the list. If it's in ~/Videos, fine. # If it doesn't exist, create it in ~/Videos. if [ -f $list ] then echo "List found at $list" else echo "Episodes list not found. Creating list arranged by season & episode..." && cd $path1 && find ~/Videos/Simpsons -name '*.avi' -o -name '*.mpg' -o -name '*.mp4' -o -type f -size +20M | sort > $list && echo "Done. List created at: $list" fi # Set the number of episodes to play. Episodes are # roughly 20 mins, so three episodes to every hour. repeat=3 cycles=0 while [ $cycles -ne $repeat ] do echo $cycles cycles=$(( $cycles + 1 )) # Read the list, select one random line. LowerBound=1 RandomMax=32767 UpperBound=$(cat $list | wc -l) RandomLine=$(( $LowerBound + ($UpperBound * $RANDOM) / ($RandomMax + 1) )) # Use sed to grab the random line. episode=$(sed -n "$RandomLine{p;q;}" "$list") # open the random line in VLC vlc -vvv --fullscreen "$episode" vlc:quit # Close the episode count loop... done # ...and then... exit