TCL secondary CT tutorial Chinese Version

[Copyright notice]
　　
Copyright (c) 1999
　　　　
This tutorial is translated by * huluwa * and is modified as needed, so that it can be freely used for non-commercial purposes.
However, this [copyright notice] Must be copied during redistribution.

[Bug]

There are many parts that cannot be translated as "letter, reaching ". Of course, you have never been "elegant" at any time. I hope you will understand.

[Original]
　
Don libes: National Institute of Standards and Technology
Libes@cme.nist.gov

[Directory]
　　
1. Summary
2. Keywords
3. Introduction
4. CT Review
5. Callback
6. passwd and consistency check
7. Rogue and Pseudo Terminal
8. FTP
9. fsck
10. Multi-Process Control: Job Control
11. interactive use of objective CT
12. Interactive CT Programming
13. non-interactive program control
14. Accuracy CT speed
15. security considerations
16. Keep CT Resources
17. Reference Books

1. [Abstract]

Modern shell provides minimum control (start, stop, and so on) for the program, and leaves the interaction feature to the user. This means that you cannot run some programs without interaction, such as passwd. Some programs can be run without interaction, but the flexibility is largely lost, such as fsck. This indicates that the construction logic of UNIX tools is starting to have problems. CT just fills in some of the cracks and solves some problems that have existed in the Unix environment for a long time.

Expect uses TCl as the core language. In addition, CT can be used no matter whether the program is interactive or non-interactive. This is a classic example of how a small language works with other UNIX tools to generate powerful functions.
　
This part of the tutorial is not about the implementation of CT, but about the use of CT language itself, which is mainly reflected through different script Description Examples. Several examples illustrate the new features of CT.
　
2. [Keywords]
　　
Reverse CT, interaction, POSIX, procedural conversation, Shell, TCL, UNIX;

3. [Introduction]
　
A Unix File System check program called fsck can be executed using the-y or-N option in the shell. In the manual [1], the-Y option is defined like this.

"All questions about fsck are assumed to be a" yes "response. When using this method, you must be especially careful because it actually allows the program to continue running unconditionally, even if you encounter some very serious errors"
　　
In contrast, the-n option is much safer, but it is practically useless. This interface is very bad, but many programs are in this style. The file transfer program FTP has an option to prohibit interactive questions so that they can run from a script. However, once an error occurs, it does not provide any handling measures.

Keep CT is a tool for controlling interactive programs. It solves the fsck problem and implements all interactive functions in non-interactive mode. Reverse CT is not especially designed for fsck. It can also handle FTP-like errors.

The fsck and FTP problems show us the limitations of user interfaces like sh, CSH and some other shells. Shell does not provide the ability to read from a program and write like a program. This means that the shell can run the fsck, but it can only sacrifice the flexibility of some fscks. Some programs cannot be executed at all. For example, if no user interface provides interactive input, it cannot run. Other programs such as telnet, crypt, Su, and rlogin cannot be automatically executed in shell scripts. There are many other applications that require user input in design.

CT is designed to interact with interactive programs. A trusted CT programmer can write a script to describe the conversation between a program and a user. The secondary CT program can run the "interactive" program without interaction. The script for writing an interactive program is as simple as the script for writing a non-interactive program. Secondary CT can also be used to automate part of the conversation, because program control can be switched between the keyboard and script.

BES [2] has a detailed description. In short, scripts are written in an explanatory language. (C and C ++ libraries are also available, but this is beyond the scope of this article). Objective CT provides commands for creating interactive processes and reading and writing their input and output. CT is named by a command with the same name.

The exact CT language is based on TCL. TCL is actually a sub-library that can be embedded into a program to provide language services. The final language is a bit like a typical shell language. There are set commands assigned to variables, if, for, and continue commands executed by the control program, and common mathematical and string operations. Of course, you can also use exec to call UNIX programs. All these functions are available in TCl. TCL provides detailed descriptions in reference books outerhour [3] [4.

CT is created on the basis of TCL. It also provides commands not available in TCl. The spawn command activates a UNIX program for interactive running. The send command sends a string to the process. The wait CT command waits for some strings of the process. Regular CT supports regular expressions and can wait for multiple strings at the same time, and perform different operations on each string. Secondary CT can also understand some special situations, such as timeout and file tail.

The reverse CT command is similar to the case command of TCL. Use a single string to match multiple strings. (As long as possible, new commands are always similar to existing TCL commands, so that the language maintains the inheritance of the tool family ). The following definition of CT is extracted from manual [5.

CT patlist1 Action1 patlist2 action2 .....

The command waits until the output of the current process matches one of the above modes, or the time exceeds a specific time length, or until the end of a file.
　　　　
If the last action is empty, you can omit it.

Each patlist consists of a schema or schema table (lists. If a pattern matches successfully, the corresponding action is executed. The execution result is returned from CT.
Precisely matched strings (or strings that have been read but not matched when timeout occurs) are stored in the expect_match variable. If the patlist is EOF or timeout, the corresponding action is executed only when the file ends or times out. generally, the timeout value is 10 seconds, but you can use a command like "set timeout 30" to set the timeout value to 30 seconds.
　　　　
The following program segment is extracted from a logon script. Abort is defined elsewhere in the script, while other actions use TCL primitives similar to the C language.

Reset CT "* Welcome *" Break
"* Busy *" {print busy; Continue}
"* Failed *" Abort
Timeout abort

Mode is a regular expression in the C shell style. The pattern must match all output starting from the previous occurrence CT or interact of the current process (so the wildcard * is used very often. However, once the output exceeds 2000 bytes, the previous character will be forgotten, which can be changed by setting the value of match_max.

The CT command does reflect the best and worst nature of the CT language. In particular, the flexibility of the keep CT command comes at the cost of frequent confusing syntaxes. In addition to the keyword mode (such as EOF and timeout), the schema tables can contain multiple schemas. This ensures that a method is provided to differentiate them. However, separating these tables requires additional scans. If they are not properly included in ["], they may take and as blank characters. Because TCL provides two string Reference Methods: Single-cited and double-cited, the situation gets worse. (In TCL, if there is no ambiguity, no quotation marks are required ). There is an independent part in the Clinical CT manual to explain this complexity. Fortunately, there are some good examples that seem to have blocked such complaints. However, this complexity is likely to be repeated in future versions. To enhance readability, the scripts provided in this article assume that double quotation marks are sufficient.

A backslash can be used for separate references. A backslash is also used to continue a statement. If a backslash is not added, the statement ends at the end of a line. This is also consistent with TCL. TCL continues scanning when it finds open single quotes or double quotes. In addition, a semicolon can be used to separate multiple statements in a row. This may sound confusing, but it is an explanatory language style, but it is indeed a pretty part of TCL.

5. [callback]

Surprisingly, How can some small scripts generate some useful functions. The following is a script for dialing numbers. He used to reverse the charge so that long-distance calls are billed on the computer. This script is activated using something similar to "reverse CT callback. Exp 12016442332. The script name is callback. exp, and + 1 (201) 644-2332 is the phone number to be dialed.

# First give the user some time to logout
Exec sleep 4
Spawn tip Modem
CT "* connected *"
Send "ATD [index $ argv 1]"
# Modem takes a while to connect
Set timeout 60
Secondary CT "* connect *"

The first line is a comment, and the second line shows how to call a UNIX program without interaction. Sleep 4 blocks the program for 4 seconds so that the user has time to exit, because the modem always calls back the phone number that the user has already used.

The following line uses the spawn command to activate the tip program, so that the output of the tip can be read by the secondary CT, so that the tip can read the input from the send. Once the tip says it is connected, the modem will ask to call the eldest brother's phone number. (Assuming modem is compatible with heshi, but this script can be easily modified to adapt to other types of modem ). CT is terminated no matter what happens. If the call fails, the reverse CT script can be designed to retry, but not here. If the call is successful, Getty detects DTR after secondary CT exits and notifies the user of loging :. (Practical scripts often provide more error detection ).

This script shows the use of command line parameters. command line parameters are stored in a table named argv (similar to the C language style ). In this case, the first element is the phone number. Square brackets make the enclosed part run as a command, and the result replaces the enclosed part. This is also very similar to the C shell style.

This script is similar to a C program of about 60 K.
　　　　

6. [passwd and consistency check]

Previously, we mentioned that the passwd program cannot run without user interaction, and passwd ignores I/O redirection, it cannot be embedded in the pipeline to read input from other programs or files. This program insists on real interaction with users. Passwd is designed for security reasons, but the result is that there is no non-interactive method to Verify passwd. Such a program that is vital to system security cannot be reliably tested, which is truly ironic.

Passwd uses a user name as a parameter and enters the password upon an interactive prompt. The following CT script uses the user name and password as parameters rather than interactive operation.

Spawn oasswd [index $ argv 1]
Set Password [index $ argv 2]
Reset CT "* password :"
Send "$ password"
Reset CT "* password :"
Send "$ password"
CT EOF

The first line uses the user name as a parameter to start the passwd program. For convenience, the second line stores the password in a variable. Similar to shell, variable usage does not need to be declared in advance.

In the third row, the exact CT search mode is "* password:", where * allows matching of arbitrary input, which is very effective to avoid specifying all details. There is no action in the above program, so the program CT will continue to run after detecting this mode.

Once the prompt is received, the next line will send the password to the current process. Indicates the carriage return. (In fact, all C's character conventions are supported ). The above program has two reverse CT-send sequences, because passwd requires two inputs to confirm the input. In non-interactive programs, this is unnecessary, but because we assume that passwd is interacting with users, we still do the script.

Finally, the line "Expect ct eof" is used to search for the file terminator in the passwd output. This line of statement also shows matching of keywords. Another keyword match is timeout. Timeout is used to indicate that all matching failures match a specific length of time. Here, EOF is necessary because passwd is designed to check whether all its I/O is successful, including the last new line generated when the password is entered for the second time.

This script is sufficient to demonstrate the basic interactivity of the passwd command. Another more complete example checks some other behaviors. For example, the following script can check other aspects of the passwd program. All the prompts are checked. Junk input check is also properly processed. Process death, unusual slow response, or other unexpected behaviors are all handled.

Spawn passwd [index $ argv 1]
Reverse ct eof {Exit 1}
Timeout {Exit 2}
"* No such user. *" {exit 3}
"* New Password :"
Send "[index $ argv 2"
Reverse ct eof {exit 4}
Timeout {Exit 2}
"* Password too long *" {Exit 5}
"* Password Too short *" {Exit 5}
"* Retype EW password :"
Send "[index $ argv 3]"
Reset CT timeout {Exit 2}
"* Mismatch *" {exit 6}
"* Password unchanged *" {exit 7}
""
Reset CT timeout {Exit 2}
"*" {Exit 6}
EOF

　　　
When the script exits, a number is used to indicate the situation. 0 indicates that the passwd program runs normally, 1 indicates unexpected death, 2 indicates locking, and so on. Numbers are used for simplicity. The string returned by CT is as simple as the number returned, even the messages generated by the derived program itself. In fact, a typical practice is to save the entire interaction process to a file, and delete the file only when the program runs as expected. Otherwise, the log will be retained for further checks.

This passwd check script is designed to be driven by other scripts. The second script reads parameters and expected results from a file. For each input parameter set, it calls the first script and compares the result with the expected result. (Because this task is non-interactive, a common old-fashioned shell can be used to explain the second script ). For example, a passwd data file is likely to be the same as below.

Passwd. Exp 3 bogus --
Passwd. Exp 0 Fred abledabl
Passwd. Exp 5 Fred abcdefghijklm-
Passwd. Exp 5 Fred ABC-
Passwd. Exp 6 Fred foobar bar
Passwd. Exp 4 Fred ^ c-

The name of the first domain is the regression script to be run. The second field is the exit value that needs to match the result. The third domain is the user name. The fourth and fifth domains are the passwords you should enter when prompted. The minus sign only indicates that there is a domain, which will never be used. In the first row, bogus indicates that the user name is invalid. Therefore, passwd will respond: no such user. When the secondary CT exits, it will return 3, which is exactly the second domain. In the last line, ^ C is actually sent to the program to verify whether the program exits properly.

In this way, objective CT can be used to test and debug interactive software, which is precisely required by the ieee posix 1003.2 (shell and Tool) consistency test. For more information, see libes [6].

7. [rogue and Pseudo Terminal]

Unix users must be familiar with the method of connecting other processes through pipelines (for example, a shell pipeline ). Secondary CT uses a Pseudo Terminal to associate with the derived process. The Pseudo Terminal provides terminal semantics so that the program thinks they are performing I/O operations with the real terminal.

For example, the BSD adventure game rogue runs in production mode and assumes that the other end of the connection is an addressable character terminal. You can use objective CT programming to play the game through the user interface.

Rogue, an adventure game, provides you with a variety of physical attributes, such as power values. In most of the time, the power value is 16, but in almost every 20 times there is a power value of 18. Many rogue players know this, but no one is willing to start the program 20 times to get a good configuration. The following script can achieve this goal.

For {} {1 }{}{
Spawn rogue
Reverse CT "* STR: 18 *" Break
"* STR: 16 *"
Close
Wait
}
Interact

The first line is a for loop, which is very similar to the control format in C language. After rogue is started, analyze CT checks whether the force value is 18 or 16. If it is 16, the program exits by executing close and wait. The two commands are used to close the connection with the Pseudo Terminal and wait for the process to exit. Rogue is launched when it reads a file Terminator, which continues to run cyclically and generates a new rogue game to check.

When a configuration with a value of 18 is found, the control rolls out the loop and jumps to the last script line. Interact transfers control to users so that they can play this particular game.

Imagine how to run this script. What you can really see is that 20 or 30 initial configurations pass through the screen in less than a second, and the last thing you leave is a game with good configuration. The only better way is to use debugging tools to play games.

We need to realize that rogue is a graphics game that uses cursors. The secondary CT programmer must understand that the movement of the cursor is not necessarily reflected on the screen in an intuitive way. Fortunately, in our example, this is not a problem. Future improvements to CT may include an embedded terminal simulator that supports character graphics areas.

8. [FTP]

We wrote the first script using keep CT and did not print "Hello, world ". In fact, it implements some more useful functions. It can run FTP in non-interactive mode. FTP is a program used to transfer files on a network that supports TCP/IP. In addition to some simple functions, the general implementation requires the user's participation.

The following script uses anonymous FTP to retrieve the next file from a host. The host name is the first parameter. The file name is the second parameter.

Spawn FTP [index $ argv 1]
CT "* name *"
Send "anonymous"
Reset CT "* password :*"
Send [exec whoami]
CT "* OK * ftp> *"
Send "get [index $ argv 2]"
CT "* ftp> *"

The above program is designed to be FTP in the background. Although they use similar mechanisms at the underlying layer, their programmable capabilities remain to be improved. Because regular CT provides advanced languages, you can modify them to meet your specific needs. For example, you can add the following features:

: Persistence-if the connection or transmission fails, you can
You can perform irregular operations based on other factors, such as user load.
Retry.
: Notification-you can send notifications via mail, write, or other programs during transmission, or even
Failed notification.
: Initialization-each user can have their own Initialization Files written in advanced languages.
(For example,. ftprc ). This is similar to C shell's use of. cshrc.

Secondary CT can also execute other more complex tasks. For example, he can use the Archie System of McGill University. Archie is an anonymous Telnet service that provides access to the database that describes files obtained through anonymous FTP on the Internet. By using this service, the script can query the location of a specific Archie file and fetch it from the FTP server. The implementation of this function only requires adding a few lines in the script above.

Currently, there are no known backend-FTP functions that can implement the above functions. Do not mention all the functions. In CT, the implementation is very simple. The implementation of "persistence" only requires adding a loop in the CT script. To implement the "Notification", you only need to execute mail and write. You can run the source. ftprc command to implement the "Initialization File". In. ftprc, you can run any CT command.

Although these features can be added with the hook function in an existing program, this does not guarantee that everyone's requirements can be met. The only way to guarantee is to provide a common language. A good solution is to integrate TCL into FTP and other programs. In fact, this is the original intention of TCL. Before doing so, reverse CT provides a solution that can implement most functions without any rewriting.

9. [fsck]

Fsck is another example with insufficient user interfaces. Fsck provides almost no way to answer some questions in advance. What you can do is to answer "yes" or "no" to all questions ".

The following program section shows how a script automatically answers "yes" to some questions and "no" to some questions ". The following script first generates the fsck process, then answers "yes" to the two types of questions, and then "no" to other questions ".

For {} {1 }{}{
Secondary CT
EOF break
"* Unref file * clear? "{Send" R "}
"* Bad inode * fix? "{Send" Y "}
"*? "{Send" N "}
}

In the following versions, the answers to the two questions are different. In addition, if the script encounters something that it cannot understand, it will execute the interact command to hand over the control to the user. The user's key is directly handed over to fsck for processing. After execution, you can press the "+" key to exit or return the control to CT. If the control is returned to the script, the script automatically controls the running of the remaining part of the process.

For {} {1 }{}{
Secondary CT
EOF break
"* Unref file * clear? "{Send" Y "}
"* Bad inode * fix? "{Send" Y "}
"*? "{Interact +}
}

Without secondary CT, fsck can run non-interactive operations only when certain functions are sacrificed. Fsck is almost unprogrammable, but it is the most important tool for system management. The user interfaces of many other tools are also insufficient. In fact, some program deficiencies have led to the birth of CT.

10. [control multiple processes: Job control]

The computation control concept of objective CT is exquisite, which avoids the common implementation difficulties. There are two problems: one is how CT handles classic job control, that is, how does CT handle it when you press ^ Z on the terminal; the other is how audit CT processes multiple processes.

The first problem is to ignore it. Regular CT has no knowledge of classic job control. For example, if you derive a program and send a ^ Z to it, it will stop (this is the perfect place for pseudo terminals) and CT will always wait.

However, in fact, this is not a problem at all. There is no need to send ^ Z to the process for an audit CT script. That is to say, there is no need to stop the next process. Secondary CT only ignores a process and transfers its attention to other places. This is the idea of controlling CT jobs. This idea has always worked well.

From the user's perspective, it is like this: when a process is started using the spawn command, the variable spawn_id is set to the descriptor of a process. The process described by spawn_id is considered as the current process. (This descriptor is exactly the descriptor of a Pseudo Terminal file, although the user treats it as an opaque object ). The reset CT and send commands only interact with the current process. Therefore, all you need to do to switch a job is to assign the process descriptor to spawn_id.

Here is an example of how to use Job control to interact two chess processes. After the two processes are derived, a process is notified first. In the following loop, each step is sent to another process. The read_move and write_move processes are left for readers to implement. (In fact, their implementation is very easy, but it is not included here because it is too long ).

Spawn chess; # Start player one
Set id1 $ spawn_id
CT "Chess"
Send "first"; # force it to go first
Read_move

Spawn chess; # Start player two
Set Id2 $ spawn_id
CT "Chess"
　　　　
For {} {1 }{}{
Send_move
Read_move
Set spawn_id $ id1
　　　　　　　　
Send_move
Read_move
Set spawn_id $ Id2
}

Some applications are not the same as the chess program. In the chess program, two player rounds flow. The script below implements a impersonate program. It can control a terminal so that users can log on and work properly. However, once the system prompts you to enter the password or the user name, until the user presses the Enter key. This effectively collects user passwords and user names, and avoids the "Incorrect password-tryagain" of common impersonating programs ". In addition, if the user connects to another host, the additional logins will also be recorded.

Spawn tip/dev/tty17; # open connection
Set tty $ spawn_id; # tty to be spoofed

Spawn Login
Set login $ spawn_id

Log_user 0
　　　　
For {} {1 }{}{
Set ready [select $ tty $ Login]
　　　　　　　　
Case $ login $ ready {
Set spawn_id $ Login
Secondary CT
{"* Password *" * login *"}{
Send_user $ expect_match
Set log 1
}
"*"; # Ignore everything else
Set spawn_id $ tty;
Send $ expect_match
}
Case $ tty in $ ready {
Set spawn_id $ tty
CT "**"{
If $ log {
Send_user $ expect_match
Set log 0
}
}
"*"{
Send_user $ expect_match
}
Set spawn_id $ login;
Send $ expect_match
}
}
　　　　　　　　

This script works like this. Connect to a login process and terminal. By default, all conversations are recorded on the standard output (via send_user ). Because we are not interested in this, we use the "log_user 0" command to disable this function. (There are many commands to control what can be seen or recorded ).

In the loop, select waits for the action on the terminal or login process, and returns a spawn_id table waiting for the input. If a value is found in the table, an action is executed in case. For example, if the string "login" appears in the output of the login process, the prompt is recorded on the standard output, and a flag is set to notify the script to start recording the user's strike key, until the user presses the Enter key. No matter what you receive, it will be displayed on the terminal, and a corresponding action will be executed in that part of the terminal of the script.

These examples show the Job Control Method of CT. By inserting yourself into the dialog, you can create a complex I/O Stream between processes. You can create multiple fan-outs and reuse fan-in and dynamic data-related process diagrams.

In contrast, shell makes it difficult for it to read a file in one row at a time. Shell forces the user to press the control key (such as ^ C, ^ Z) and keywords (such as FG and BG) to switch jobs. These cannot be used in the script. Similarly, a shell running in non-interactive mode does not process "History" and other features that are only designed for interactive use. This is also similar to the previous passwd program. Similarly, you cannot write shell scripts that can regression test shell actions. As a result, shell cannot be thoroughly tested.

If you use javasct, you can use its interactive job control to drive shell. A derived shell considers it to be interactive, so it can process job control normally. It not only solves the problems of Shell and other programs that handle job control. The shell can also be used to process jobs in place of reverse CT when necessary. You can use shell-style job control to support running processes. This means: first derive a shell, and then send the command to shell to start the process. If a process is suspended, for example, if a ^ Z is sent, the process stops and returns the control to shell. For reverse CT, it is still processing the same process (the original shell ).

The wide CT solution not only has great flexibility, but also avoids repeated job control software that already exists in shell. By using shell, you can select the shell you want to derive, so you can obtain job control as needed. In addition, once you need it (for example, when testing), you can drive a shell to make it think it is running interactively. This is also important for programs that detect whether they change the output buffer after interactive running.

For further control, during interact execution, objective CT sets the control terminal (the terminal that started the objective CT, rather than the Pseudo Terminal) to the production mode so that the characters can be correctly transmitted to the derived process. When the interact is not executed on the secondary CT, the terminal is in the familiar mode, and the job control can act on the secondary CT itself.

11. [interactive use of CT]

As mentioned above, you can use the interact command to interactively use scripts. Basically, the interact command provides free access to conversations, but we need more refined control. This can also be achieved using secondary CT, because secondary CT reads the input from the standard input is as simple as reading the input from the process. However, we need to use expect_user and send_user for standard I/O without changing the spawn_id.

The following script reads a row from the standard input within a certain period of time. This script is called timed_read and can be called from CSH. For example, set answer = "timed_read 30" can be called.

#! /Usr/local/bin/CT-F
Set timeout [index $ argv 1]
Expect_user "*"
Send_user $ expect_match

The third line receives any row ended with a new line from the user. The last line returns it to the standard output. If no input is obtained for a specific period of time, the return value is empty.

The first line supports "#! . (If you add the executable property to the script property, do not add the reverse CT before the script ). Of course, scripts can always be started explicitly with "Keep CT scripot. The options after-C are executed before any script statement is executed. For example, do not modify the script itself. Simply add-c "trace..." to the command line. This script can be added with the trace function (the ellipsis indicates the trace option ).

You can add multiple commands in the command line as long as they are separated by ";" in the middle. For example, the following command line:

Reverse CT-c "set timeout 20; spawn Foo; reverse CT"

Once you have set the timeout period and the program starts, wait CT to wait for the file terminator or a timeout period of 20 seconds. If you encounter an EOF, the program stops, and then returns CT. If a timeout occurs, reverse CT will return. In both cases, the current process is killed implicitly.

We can still learn a lot if we don't use the functions of the above two examples. In both cases, the common solution is to fork another sleep sub-process and use signal to notify the original shell. If this process or read occurs first, shell will kill the sleep process. Passing PID and preventing background processes from generating startup information is a headache for others except top-level shell programmers. Providing a general method to start multiple processes like this will make shell scripts very complicated. So it is almost certain that programmers generally use a special C program to solve such a problem.

Expect_user, send_user, send_error (output to the standard error terminal) are relatively long and frequently used in translating complex interactions from processes into simple interaction CT scripts. In [7], Libs describes how to use the script to secure the package (WRAP) ADB, and how to free the system administrator from the details of the ADB, at the same time, the system crash caused by incorrect keys is greatly reduced.

A simple example allows FTP to automatically retrieve files from a private account. In this case, a password is required. Even if file access is restricted, you should avoid storing passwords in plaintext. It is not suitable to use passwords as parameters for script running because they can be seen using PS commands. One solution is to call expect_user at the beginning of script running to allow users to enter the password that may be used in the future. This password must only be known to this script, even if you have to retry FTP every hour.

This technique is useful even if the information is entered immediately. For example, you can write a script to change the passwords of different accounts on each host, regardless of whether they use the same password database or not. To manually implement this function, you must telnet to each host and enter a new password. However, you can only enter the password once for the script to do other things.

Expect_user and interact can also be mixed in a script. When debugging a program loop, you may fail after several steps. Which debugger can a trusted CT script drive, set the breakpoint, execute several steps of the program loop, and then return the control to the keyboard. It can also switch back and forth between the loop body and the condition test before the return control.