Unix Programming - Designing Minilanguages - Language or Application Protocol?
Another important question you need to ask is whether your
minilanguage engine will be called interactively by other
programs, as a slave process. If so, your design should probably look
less like a conversational language for human interaction and more
like the kind of application protocols we looked at in Chapter5.
The main difference is how carefully marked the boundaries
of transactions are. Human beings are good at spotting where
conversational output from a CLI ends, and where the prompt for the
next input is. They can use context to tell what's significant and
what should be ignored. Computer programs have much more trouble with
this. Without either unambiguous end markers on output or advance
knowledge of the length of the output, they can't tell when to stop
Even worse is when a program's input is buffered (often
inadvertently, as by stdio). A program that stops overtly reading at
the right place can nonetheless eat past it.
Programs in which master processes are trying to do interactive
things with slaved minilanguages that are not carefully designed
around this problem are prone to deadlock as the master and slave fall
out of synchronization (a problem we first noted in Chapter7).
There are workarounds for driving minilanguages that are not so
carefully designed. The prototype for most of them is the
expect package. This package
assists conversation with CLIs. It's built around the following
operation: read from slave until either a given regular-expression
pattern is matched or a specified timeout elapses. With this (and, of
course, a send-to-slave operation) it's often possible to construct
master programs to do reliable dialogues with slave processes even
when the latter have not been tailored for the role.
Workalikes of the expect package in
other languages are available; a Web search for the name of your
favorite language with the added keywords “Tcl expect” is
quite likely to turn up something useful. As a minilanguage designer,
however, you would be unwise to assume that all your users will be
expect gurus. Even if they are, this is an
extra glue layer and a place for things to go wrong.
Be aware of this issue when designing your minilanguage. It may
be a good idea to add an option that changes its conversational
behavior to make it respond more like an application protocol, with
unambiguous end-of-output delimiters and an analog of
[an error occurred while processing this directive]