DropScript

Or How to Build a Way Easy Yet Spiffy App

Quick, I need a demo

Last year at Apple's Worldwide Developers Conference I was giving a talk on BSD in Mac OS X. Basically, I was standing in front of a (full) room of Macintosh developers explaining why Unix is good for Mac OS.

There has been a fair amount of debate over the value of keeping the BSD command line (Terminal.app) and the BSD toolset in the base operating system. Many argue that it should not be present in the base system: The majority of Mac OS users will not need to interact with the command line, and therefore the Terminal will not be of great use to them. The very presence of the command line option in the system will give developers an undesireable crutch; as a result users might end up being forced use the command line. Instead, developers should be forced to come up with real solutions that do not rely on the command line.

I agree that Terminal.app is not a necessity in the base system, though I'm glad it's there for my own convenience. (It is a necessity in the developer toolset.) I also agree that requiring users to deal with the decidedly arcane Unix interface would be a grave mistake. However, even with no way to get to an interactive command line, the presence of the BSD toolset in the standard installation of Mac OS is of great value to developers and therefore to users. My argument is simple: the BSD commands provide another valuable API to developers; they enable software authors to do great things will less effort.

In order to make my case that the BSD toolset is important, it helps to have a good demo for the talk, in true WWDC fashion; I wasn't inclined to let the QuickTime folks get all of the applause. BSD provides may small programs (often called commands, as they are often invoked by users on an interactive command line) each of which performs some specialized function. A command called cp, for example, can copy a file; another, mv, can move a file. An application author can write programs that invoke BSD commands to do certain tasks. These commands can be shell scripts which in turn may invoke several other commands in sequence. I figured that an application that did this would be a good demo.

I had heard of an application for NeXTStep (I can't remember the name, as I've never seen it), which would let you graphically create a shell script by chaining commands together. That sounded hard to write in a week... I've also seen people use MacPerl, which lets you create droplets, applications onto which you can drop a file and have a perl script process the file for you. Now wouldn't it be cool if you could take any BSD command and turn it into a drop application? That didn't sound so hard, so I started thinking about it.

Designing a surprisingly simple application

What I needed was an program that could turn a command line tool into an application. Many command line tools operate on files: you invoke the program by name and give it file names are arguments. For those of you not familiar with the command line, the basic usage is fairly simple. Mac OS X includes a program called gzip, which will compress a file. If I want to compress the file Big File, I type the following into the terminal:

gzip "Big File"

and I end up with a smaller file called Big File.gz. (The .gz file name extension denotes a gzip-compressed file.) Now I want to be able to do the same thing in Finder by dragging a file onto an icon rather than using the command line.

My droplet-generating program therefore needs to create a new application which invokes the desired command (typically a shell script)¹ for me, with my file as an argument. I started by writing a droplet application which I would use as a template, thinking that the droplet generator would copy the template application and replace the command it invokes with one specified by the user. I wanted to avoid the need to compile a new binary, since many users will not have the developer tools installed; while it's probably OK that only developers can create droplets, I'd rather not require the developer tools if I don't need to.

Writing the primordial droplet

My plan was to create an application which would contain a shell script in it as a resource. Whenever the application is asked to open a file, it will invoke the script with the file's path as an argument. The generator would therefore only need to copy the original app and replace the script resource with a new one.

I decided to write the application using Cocoa. Mostly, this is because Cocoa is the only application toolkit I'm any proficient at (I don't write many apps), but the reason Cocoa is the only toolkit I know is that Cocoa is an excellent toolkit. Cocoa does an admirable job of minimizing the amount of work I need to do. For example, when a user drops a file onto an application with Finder, what happens is that Finder launches the application and sends it an AppleEvent telling it to open the file. I'll be needing to handle these events in this application, but I'm not going to have to write any code to handle AppleEvents; Cocoa will provide that for me.

I start by creating a new Cocoa Application project in Project Builder. In the resources group of the project, I add an new empty file called "script" which will contain my prototype shell script. We'll start with a simple script:

#!/bin/sh
gzip -9 "$@"

This script will compress files with gzip using the maximum compression level.

Most Cocoa applications instantiate an object termed a controller. This object reacts to user actions and drives the application. Very often the controller is "owned" by the main user interface; I'll do that for this app, but more on that later. First, I'll consider what the controller needs to do.

For this app, I already know that it needs to be able to open a file, so I'll define a method called open:. open: is what is called an action; these are methods which are called by other objects to trigger some activity in the application. AppKit interface elements can be set up to invoke an action on another object, called its target. For example, pressing a button or sliding a slider with cause the button or slider to send an action to its target. Action methods always take one argument: the id of the object which sent the action message to the target. The interface for our controller object (which I'll call a DropController) follows:

#import <Foundation/NSObject.h>

@class NSString;

@interface DropController : NSObject

/* Instance variables */
{}

/* Actions */
- (IBAction) open: (id) aSender;

@end

Next, I open up the MainMenu.nib file in the project, which opens in Interface Builder. I then import the header DropController.h (click on the Classes tab, and use the Classes->Read Files... menu item), and instantiate that object (Classes->Instantiate) in the nib file. When the application is launched, the MenMenu.nib interface (which is the main application interface) is loaded automatically. It will in turn instantiate the DropController object. I want the File->Open menu item to invoke the open: action in the controller, so I simply connect the menu item to the controller and set its action to open:. (You'll be wanting to go through an Interface Builder tutorial if I've lost you; If you want to take my word for it, this is very easy.) And because I won't be needing them, I can delete all of the menu items other than the Apple menu and the File->Open item.

If you are new to Interface Builder, that was the hard part. The rest is a breeze from here.

I need to locate the path to the shell script (or command) I've put into the application (it'll be in the Resources folder within the app), so I'm going to keep that information in an instance variable of the controller. I therefore edit DropController.h to add an instance variable:

/* Instance variables */
{
@private
  NSString* myScriptFileName;
}

myScriptFileName is a string we'll keep the path to the script in. (Side note: I make a habit of always marking my instance variables as private, as letting other objects access them directly is almost always a mistake. Other classes may not directly modify a private instance variable, but must instead use the provided API; this is a core tenet of data encapsulation.)

We can begin writing the implementation of the controller (DropController.m) now:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#import "DropController.h"

@implementation DropController

/* Inits */

- (id) init
{
  if ((self = [super init]))
    {
      myScriptFileName =
        [[[NSBundle mainBundle] pathForResource:@"script" ofType:nil] retain];
    }
  return self;
}

- (void) dealloc
{
  [myScriptFileName release];

  [super dealloc];
}

/* Actions */

@end

The init method initializes the instance variables, which in this case sets the path to the script into myScriptFileName and retains the string (marks it so that it isn't deallocated until we are done with it). When the controller is discarded (the app quits), the dealloc method releases the string (expresses the controller's sudden disinterest in the string's safety).

And then I tell the controller how to open a file by implementing the open: action:

/* Actions */

- (void) runScriptWithFiles: (NSArray* ) aFileList
{
  [NSTask launchedTaskWithLaunchPath: myScriptFileName
                           arguments: aFileList];
}

- (IBAction) open: (id) aSender
{
  NSOpenPanel* anOpenPanel = [NSOpenPanel openPanel];

  if ([anOpenPanel runModalForTypes:nil] == NSOKButton)
    {
      [self runScriptWithFiles: [anOpenPanel filenames]];
    }
}

The open: method creates an open panel and runs it modally, then runs the script on the selected files. I put the actual code to run the script in its own method because I'll be needing it again later.

At this point, I have an application which I can launch, then bring up the File->Open menu, and have it run its script on a file (or a set of files) for me. But I still need to handle AppleEvents from the Finder or other sources. AppKit makes this easy. The AppKit application object (which I am using already, though I've not had to know it yet) handles AppleEvents for me. All I need it to ask it to tell me when it gets an open message.

First, I go back to the MainMenu.nib in Interface Builder. We need to mark the controller object as the delegate of the application object. A delegate is an object to which another object sends specific methods when something interesting happens. In Interface Builder, we connect the File's Owner object (which, for MainMenu.nib is the application object) to the controller object as the delegate.

If the application's delegate implements the method application:openFile:, the application will call that method whenever the application is asked to open a file (this and other delegate methods are documented in the NSApplication docs), such as when it is asked to open a file via AppleEvents. All I have to do, then, it implement the method:

/* Application deletate */

- (BOOL) application: (NSApplication*) anApplication
    openFile: (NSString*     ) aFileName
{
  [self runScriptWithFiles: [NSArray arrayWithObject: aFileName]];

  return YES;
}

Now dropping files onto the droplet's icon works! With that, I've finished up the prototype droplet, which can compress files.

Writing the droplet generator

The droplet generator should itself be an application, so that I do not need access to the terminal. In fact, I'd like to be able to write a shell script in Text Edit, and then drop that file onto my droplet generator. That is, the droplet generator itself should be a droplet. Well... huh... I just wrote one of those. All this droplet needs to do different is that instead of compressing a file, it needs to copy the prototype app and replaces the shell script inside. Well... huh... I can do that with a shell script a lot more easily that in C (even Objective-C) code. So it seems all I have to do here is replace the gzip script with a script that copies the application (itself!) and puts the new script in the right place. The droplet generator iteself becomes the prototype droplet. (Being lazy, like most programmers, this was an exciting revelation.) A simple script to do this might look like this:

#!/bin/sh -e

ScriptFileName=$1; shift

 DropScript="$(echo $0 | sed 's|\.app/.*$|\.app|')"
Destination=$(dirname "${ScriptFileName}")
DropperName="Drop"$(basename "${ScriptFileName}" | sed 's/\..*$//')
 NewDropper="${Destination}/${DropperName}.app"

mkdir "${NewDropper}"
pax -rw . "${NewDropper}"
chmod u+w "${NewDropper}/Contents/Resources/script"
cp -f "${ScriptFileName}" "${NewDropper}/Contents/Resources/script"
chmod 555 "${NewDropper}/Contents/Resources/script"

For more information

The complete source code to DropScript is available via the Darwin CVS server at Apple, in the DropScript CVS module. You can download a pre-built executable from my home page at MIT at http://www.mit.edu/people/wsanchez/software/.

These are a few features in DropScript which were omitted from this article for simplicity, such as:

The primordial shell script is actually more complicated, as it does some rudimentary error checking.
In order to emulate the behavior of StuffIt Expander, which is probably the most familiar drop application for Mac OS users, I added a little code to have the droplets quit after processing a file if they weren't otherwise already running.
There is now a mechanism by which you can specify the file types that your new droplet accepts within the shell script.
There is an about box and a useless preferences panel.

1: Some commands don't take file names as arguments and most commands have some special options you might want to use. The most flexible way to create droplets would therefore be to write a shell (or perl/python/etc.) script that takes file name arguments and invokes the right command(s) with the right option(s), and use that script as the command in your droplet.

This article was originally published in MacTech Magazine, Volume 17, Number 8, August 2001.