Exploring Expect

Dealing With Programs That Miss Input

A problem related to buffer flushing can happen when Expect is used to drive modems or other communications devices. Serial interfaces (i.e., UARTs) can go through states during which time they cannot accept input. For example, characters are ignored when the speed or some other characteristic of the interface is changed. This also occurs when making initial connections (via telnet, tip, kermit, etc.) to a new host, modem, or communications switch.

Consider the following fragment used to dial a Hayes-compatible modem:

spawn tip modem
expect "connected"
send "atd1234567\r"
expect "CONNECTED"

When run, tip says the modem is connected but yet it does not respond. Mysteriously, when you do the same interaction by hand, it works fine.

The problem is that the modem is not yet listening when you have sent the dial command to it. It may seem like the modem ought to be listening, but in fact all the "connected" message means is that the UART control lines (e.g., DTR) have been raised. The modem then has to initialize itself. If you do not allow time for the initialization, the modem will miss your command.

Unfortunately, Hayes-compatible modems do not prompt, so you cannot use a simple expect command to wait. Inserting a brief pause is a simple enough solution. However, the most reliable solution is to loop, sending AT commands and waiting for an OK in response before sending anything further.

Some systems exhibit even worse problems—due to a limited hardware ...