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.
MODULARITY AND FACTORING
Shell scripting languages such as sh and csh in UNIXreg., as well as MPW, have always
taken a rather cavalier approach to code organization. Most configuration is achieved
with a global namespace of environment variables. This is a problem with ToolServer,
because you don't want to load your entire set of MPW startup scripts every time you
run a command. Even if you wanted to, you couldn't -- ToolServer doesn't have text
editing, menu bar customization, or other user interface elements of the MPW Shell,
so it's missing several built-in commands. Your existing startup scripts won't work,
and some utility commands may also fail.
Three principles from structured software design are useful here:
Let's take a concrete example. Many of us cut our teeth as programmers on UNIX.
Initiates of this brilliant but byzantine operating system tend to grow fond of its
command set, in much the same way that cabalists become attached to bizarre
metaphysical formulas purporting to explain the universe. A UNIX wizard's MPW
startup script usually contains a list of aliases to translate between UNIX and MPW:
Alias ls Files, Alias cp Duplicate, and so on. These commands are then used in all the
wizard's utility scripts as well. This creates a problem with ToolServer: it can't use
these startup scripts because they also customize the user interface with commands
like AddMenu and SetKey. Without the aliases, though, the utility scripts won't run.
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.
ToolServer implements most of the MPW Shell's I/O system, which is based on the
stdio library and UNIX-style redirection. However, it doesn't read keyboard input or
display text output. All of its I/O channels are ultimately files, pipes, or the
pseudodevice Dev:Null.
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.
There are several ways to package commands for use with ToolServer. The most basic
and boring ways are:
There are more interesting deployment modes, but they require a bit more
explanation.
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 ofdevelop, I provided
sample code for interacting with SourceServer (another Apple event-driven MPW
Shell subset), and that code can easily be adapted for ToolServer.
Because it's tied to a command-line interface, the MPW toolset has come to seem
rather archaic, but there's life in the old girl yet. ToolServer's support for Apple
events and AppleScript allows innumerable improvements in its interface. In the
future, we may see friendly front ends for various MPW tools, as well as deeper
support for compilation and other kinds of file processing with MPW tools in
third-party development systems.
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.