|
Unix Programming - Unix Interface Design Patterns - The Cantrip Pattern
The Cantrip Pattern
The cantrip interface design pattern is the simplest of all. No
input, no output, just an invocation and a numeric exit status. A cantrip's
behavior is controlled only by startup conditions. Programs don't
get any more scriptable than this.
Thus, the cantrip design pattern is an excellent default when
the program doesn't require any runtime interaction with the user
other than fairly simple setup of initial conditions or control
information.
Indeed, because scriptability is important, Unix designers learn
to resist the temptation to write more interactive programs when
cantrips will do. A collection of cantrips can always be driven from
an interactive wrapper or shell program, but interactive programs are harder
to script. Good style therefore demands that you try to find a cantrip
design for your tool before giving in to the temptation to write an
interactive interface that will be harder to script. And when
interactivity seems necessary, remember the characteristic Unix design
pattern of separating the engine from the interface; often, the right
thing is an interactive wrapper written in some scripting
language
that calls a cantrip to do the real work.
The console utility
clear(1),
which simply clears your screen, is the purest possible cantrip; it
doesn't even take command-line options. Other classic simple examples
are
rm(1)
and
touch(1).
The
startx(1)
program used to launch X is a complex example, typical of a whole
class of daemon-summoning cantrips.
This interface design pattern, though fairly common, has not
traditionally been named; the term “cantrip” is my
invention. (In origin, it's a Scots-dialect word for a magic spell,
which has been picked up by a popular fantasy-role-playing game to tag
a spell that can be cast instantly, with minimal or no
preparation.)
[an error occurred while processing this directive]
|
