Expect is also limited in its knowledge of character graphics such as is done by Curses.
Nonetheless, with a little scripting, testing and automation of character graphics can be
accomplished, and in Chapter 19 (p. 453), I will describe one way of doing this.
Ultimately, I believe that Expect will do best with this capability built in rather than
provided via scripts. However, the requirements and interfaces are not obvious, and
further experimentation and design is required. ExpecTerm is an example
implementation of a built-in character-graphic capability based on an earlier version of
Expect. ExpecTerm is available from the Tcl archive (see page 19).
1.9. A Little More About Tcl
Expect's language is general-purpose. It has control structures and data structures so that
you can do just about anything. This can make up for the lack of programmability in
other programs. For example, most debuggers do not provide very sophisticated
methods of programmed control. Typically, you cannot declare variables and are
restricted to simple loops.
The core of Expect's language facilities are provided by Tcl, a language used by many
other tools. "Tcl" stands for Tool Command Language. It comes as a library intended to
be embedded in applications, providing a generic language facility to any application.
Tcl solves a long-standing problem in designing application languages.
Actually, most tools do not have very sophisticated internal control languages. The shell
represents the extreme—it has a very rich language and can even call upon other
programs. Start-up scripts such as .cshrc and .profile can be very complex. Few
programs have such flexibility. And that is just as well. Such programs each have their
own language and it is daunting to master each new one.
In the middle of the spectrum are programs such as ftp that have a limited ad hoc
language—such as permitted in the file .netrc—not very flexible but better than
nothing. A lot of programs are designed like ftp—their languages are limited, not
extensible, and different from one tool to the next.
At the far end are programs such as telnet which have no control language
whatsoever. The bulk of all interactive programs are like ftp and telnet—severely
lacking in programmability.
This lack of programmability is understandable. Consider writing an application that
controls the printer. It is not worth writing a big language that requires a scanner, a
parser, symbol table, etc. The application alone might only be 10Kb. However, it is
impossible to predict what uses you might put your program to in the future. Suppose
you get another printer. Then your program needs to understand this. Suppose you give
your program to someone else and they have two printers but they are of two different
types. Suppose they want to reserve one printer for printouts of a special kind for a day
—printing checks on payday, for example. You can see that the possibilities are endless.
So rather than customizing the application each time and extending the language as
required (if you have not boxed yourself into a corner already), it makes sense to use a
general-purpose language from the beginning.