MPW comes with dozens of useful tools and scripts. They're handy for a lot of things besides programming -- or would be, if you were willing to keep the MPW Shell open all the time, and if they weren't based on command lines. Fortunately, the Shell is not the only way to use them: a small application known as ToolServer makes it possible to run MPW commands in a standalone mode. You can write double-clickable MPW scripts, give MPW commands from AppleScript, and write front ends to tools in high-level programming languages.
Using ToolServer isn't exactly like using the MPW Shell. There are caveats if you want to write scripts and tools that will work in both environments. We'll first take a look at these issues and then explore how to package commands for use with ToolServer.
Three principles from structured software design are useful here:
One solution to this problem combines the first two principles listed above. First, separate the aliases from the user interface setup code, yielding two different startup files. Both files are invoked by the MPW Shell startup process but neither is invoked at ToolServer startup. Second, instead of assuming a particular global configuration, make each utility script explicitly include whatever setup files it may require. MPW's analog of the #include directive of C is Execute, which executes a file in the current namespace.
We can apply common C bracketing conventions to avoid multiple inclusion of the same file. Assuming that our UNIX wizard has split off his or her aliases into a file named UNIXAliases, a script using these aliases would start -- after the header comment -- as follows:
if {__UNIXALIASES__} == ""
execute UNIXAliases
end
The
script file UNIXAliases would set the variable __UNIXALIASES__ to something
other than the empty string, and decline to execute itself again if it had
already been executed, like so:
if {__UNIXALIASES__} == ""
set __UNIXALIASES__ "true"
... # the aliases go here
end # __UNIXALIASES__
A
different solution to the same problem involves the third principle, reducing
dependencies between modules. Utility scripts don't really need to use csh
commands, after all: the aliases are there mostly so that the wizard can type
them into the MPW Shell, his or her fingers having long ago locked into an
inflexible pattern of TTY interaction. If scripts don't assume the availability
of a different command set -- that is, if they stick with the MPW command
names -- the aliases need not be included at all.Independence is a good idea for another reason: you may give your ToolServer scripts to other people at some point in your long and happy life. The more your commands depend on the global environment, including ToolServer startup files, the more likely they are to conflict with another user's environment.
The only mechanisms for interacting with the user in ToolServer are commands like Alert and Confirm that display dialog boxes, and interface tools you write yourself. Even these must be used with caution, since ToolServer can run remotely over a network, and hanging a server machine by bringing up a dialog box is often regarded as undesirable.
It helps to separate user interface code from core code, as already discussed. Commands you intend to run with ToolServer should not have a user interface: they should perform an action that's completely specified by their command line. An outermost user interface script can present choices to the user, then invoke an innermost command that has no user interface. The outermost script is just for ToolServer; the inner script or tool is suitable for both ToolServer and the MPW Shell.
You can detect when a command is running under ToolServer and squelch its user interface by looking at the environment variable BackgroundShell. This is the empty string when running under the MPW Shell, but it's nonempty under ToolServer. Most user interactions in MPW commands are just confirmation alerts, so if execution reaches a Confirm command and BackgroundShell is set, assume that the user would answer "no." All commands that require confirmation should support the -y and -n options, which provide answers on the command line, and these options should be provided when the commands are used from ToolServer.
Some MPW commands, such as Make and Backup, write output to the Worksheet, and the user then selects and executes the output. This model doesn't apply to the ToolServer environment since it has no Worksheet. The easiest solution is to redirect the command output to a temporary file, execute that file, and then delete it. This is less selective than using the Worksheet, which allows the user to decide which lines to execute. If selectivity is important, you can write a command that presents the lines of output to the user and allows them to be independently accepted or rejected.
We don't live in the best of all possible worlds, St. Thomas Aquinas and Dr. Pangloss to the contrary, and so commands often return errors. These generate text that's directed to the standard error channel. In the MPW Shell, error text goes to the frontmost window by default, but in ToolServer, the default is a file named command.err in the folder containing the command file. This is very antisocial behavior, especially since commands invoke other commands and the error file could wind up buried at some arbitrary-seeming place in your folder tree. Redirect the standard error channel to save yourself from Sisyphean levels of frustration whenever something goes just a little bit wrong.
There are two ways to redirect errors. First, you can use the standard MPW error redirection characters >=, >=>=, [[Sigma]], and [[Sigma]][[Sigma]] in your outermost user interface script. For instance, the script line
Veeblefetzer >= "{Boot}"Veeblefetzer.Errors
would
redirect errors to the file Veeblefetzer.Errors at the top level of your
startup disk. This does little or nothing to bring the errors to your
attention, though, so your outermost script should look something like this:
Set ErrorFile "{TempFolder}"MyUtility.Errors
Delete -i "{ErrorFile}"
Set Exit 0 # Don't bomb quietly on errors
Potrzebie >=>= "{ErrorFile}"
if {Status} == 0
Veeblefetzer >=>= "{ErrorFile}"
end
if `Exists "{ErrorFile}"`
Alert `Catenate "{ErrorFile}"`
Delete -i "{ErrorFile}"
end
The
other way to redirect errors is to set the ToolServer built-in variable
BackgroundErr to the name of a file. This will create that file whenever
there's an error. This is somewhat less flexible than redirection, but it can
be set once and for all in a ToolServer startup script. That would make the
script above read like this:
Delete -i "{BackgroundErr}"
Set Exit 0 # Don't bomb quietly on errors
Potrzebie
if {Status} == 0
Veeblefetzer
end
if `Exists "{BackgroundErr}"`
Alert `Catenate "{BackgroundErr}"`
Delete -i "{BackgroundErr}"
end
Standard
output can be controlled similarly, using either redirection characters or the
environment variable BackgroundOut.
Standalone scripts. If you change the creator of a script file to 'MPSX', double-clicking it in the Finder will launch ToolServer and send it an Open Document event, causing it to be executed. Use this approach for your outermost user interface scripts. To change the creator, use MPW's "SetFile -c 'MPSX' file" command.
There is, alas, no such thing as a standalone tool, but you can write a one-line script that invokes a tool with any parameters or none.
AppleScript. ToolServer is fully scriptable. Aside from the four required commands, it has only one scripting command, the dreaded DoScript. This takes a command written in another scripting language -- MPW command language in this case -- and passes the command to its script interpreter. DoScript is discouraged in new applications because it's unstructured, but it's very useful for pre-AppleScript applications that have their own languages.
A simple AppleScript script confers few benefits over a standalone ToolServer script. In fact, it's better to avoid mixing scripting languages if you can. However, using FaceSpan or another AppleScript authoring tool, you can use AppleScript to set up a conventional application that relies on ToolServer as a workhorse. Simply pass DoScript commands in response to user actions, redirecting errors and output to temporary files that you interpret in your AppleScript code.
Apple events. Finally, you can take AppleScript one step further, driving ToolServer directly with Apple events generated from compiled software. This delivers the maximum in flexibility and performance. You could even write a project-file development system based on MPW compilers. Another possibility would be HyperCard XCMDs, allowing MPW commands to be invoked from HyperTalk. An Apple event front end could be created for a particular MPW tool, allowing it to be cleanly invoked from other scripts or compiled software; this might also provide a simple user interface for controlling it with dialogs and menus.
ToolServer accepts the required Apple events, as well as DoScript and some special-purpose events related to status checking, command canceling, and error and output redirection. These are documented in Chapter 4 of the ToolServer Reference manual that comes with MPW. In this column in the last issue of develop, I provided sample code for interacting with SourceServer (another Apple event-driven MPW Shell subset), and that code can easily be adapted for ToolServer.
Ultimately, MPW's command-line interface is destined to become a fading memory. Although it confers some advantages in power, it must give way to friendlier approaches in the end. However, if we fail to move its toolset forward into the post-command-line world, we will be poorer for the loss.
TIM MARONEY was discovered on the Isle of Wight by seal farmers in the Year of Our Lord 1394, and again seventy years later by Tasmanian basket twirlers out for a stroll in the Yukon. The little tyke pursued a happy life of fun, freedom, and quantum mechanics. He resurfaced in 1961, in the town of Holyoke, Massachusetts. Tim played a magician in bondage in a class play in the second grade, which may have prepared him for the contract work he's now doing at Apple.
Thanks to Deeje Cooley, Arno Gourdol, and Rick Mann for reviewing this column.
