---

Wrapping a Command Line Application with a GUI Interface

Command line applications are a good first step in writing software for Mac OS X. However, most Mac OS X users tend to shy away from the command line (former UNIX and Linux users notwithstanding). For this reason, if you want your command line application to have mass appeal, you should consider wrapping it in a GUI interface.

Mac OS X provides a number of methods for wrapping a command line application with a GUI interface. These include:

• Do Shell Script (AppleScript Studio)

• NSTask (Cocoa)

Each provides different capabilities for different purposes. This section points you to existing documentation on the topic and describes common issues that arise when wrapping a command line application with a GUI interface.

This section is primarily intended for open source developers, shareware/freeware developers, and in-house UNIX application developers, as these techniques do not offer the same level of functionality that you can get through tighter integration between the GUI and the underlying application.

In this section:

Choosing a Wrapping Method
File Access Considerations
For More Information

Choosing a Wrapping Method

If you just need to run a shell script by double-clicking it, and have no need for a GUI, you can simply rename the shell script to end with .command and it will open in Terminal automatically.

If you need more control over arguments but the command-line tool is non-interactive—that is, the GUI wrapper will merely start it and display the results—then either NSTask or "Do Shell Script" is acceptable, and you should use whichever one is most comfortable.

If the application needs to interact with the tool in any way, you should use the function NSTask. With it, you can chain arbitrary numbers of tasks using the NSPipe function.

File Access Considerations

Carbon, Cocoa, AppleScript, and other Mac OS X development environments deal with files by using file references rather than referring to them by their path. As a result, you can move files anywhere on the disk and the file reference will still be valid even though the path has changed.

Using file references presents two problems for the developer. First, you have to explicitly convert them to POSIX paths to use them as the argument to a shell script. Second, the POSIX paths can contain spaces, so you must construct the command line carefully to prevent the script from failing if a directory name (or the name of your hard drive) contains a space.

Because of the potential side effects, you should always use the quoted form of the POSIX path when passing the path to a shell script. This is described in detail in Technote #2065: Issuing Commands.

The issue of spaces in pathnames is also a slight issue for Cocoa developers using the NSTask API, usually because of bugs in the shell script itself. (You do not need to escape strings passed as arguments using NSTask.)

You should always test any GUI-wrapped command-line application with filenames that contain spaces and other strange characters such as double quotes (“) and trademark (™) to make sure that there are no unexpected failures.

For More Information

For more information on AppleScript’s Do Shell Script command, see Technote #2065: Issuing Commands, at http://developer.apple.com/technotes/tn2002/tn2065.html or the “simple sheet” example in AppleScript Studio.

For more information on Cocoa’s NSTask API, see Interacting with the Operating System.

---