EXPECT Tutorial Chinese Edition
Create time: 2001-04-29
Article properties: reprint
Article Source: China University of Science and Technology BBS Station
[Copyright Notice]
CopyRight (c) 1999
This tutorial is translated by * gourd baby * and has made appropriate modifications, freely for non-commercial purposes.
But the redistribution must be copied [copyright statement].
[Bug]
There are a lot of part, and when translation is translated, I can't make "letters, Da". Of course, there is no "Ya" at any time, I hope you understand.
[original]
DON Libes: National Institute of Standards and Technology
Libes@cme.nist.gov
[table of Contents]
Abstract
2. Keywords
3. Introduction
4. Overview of Expect
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 Expect
12. Interactive Expect Programming
13. Control of non-interactive procedures
14.Expect speed
15. Safety considerations
16.ExPect Resources
17. Reference book
1. [Summary]
Modern shell provides minimal control (start, stop, etc.), and left the characteristics of the interaction to the user. This means some programs that you can't run non-interactive, such as Passwd. There are some programs that can run non-interactive, but largely lose flexibility, such as FSCK. This indicates that UNIX's tool constructive logic begins to have problems. EXPECT has filled some of the cracks to solve some problems in the long-term in the UNIX environment.
EXPECT uses TCL as a language core. Not only that, but whether the program is interactive and non-interacting, Expect can be used. This is a classic example of a small language and other tools of UNIX to produce powerful functions.
This part tutorial is not related to the implementation of Expect, but is the use of the Expect language itself, which is mainly reflected by different script description examples. Several examples also illustrate several new features of Expect.
2. [Keyword]
EXPECT, interaction, POSIX, programized dialogue, shell, tcl, unix
3. [Introduction]
A UNIX file system checker called FSCK can be executed from the -Y or -N option from the shell. In the manual [1], the definition of the -y option is like this.
"All questions for FSCK assume a" YES "response; when used in this way, it must be particularly careful because it actually allows the program unconditional to continue to run, even if it encounters some very serious mistakes."
In contrast, the -n option is safe, but it is actually almost almost a little. This interface is very bad, but there are many programs are this style. File Transport Program FTP has an option to disable your interactive questions so that you can run from one script. But once an error has occurred, it does not have a handling measures.
EXPECT is a tool for controlling an interactive program. He solved the problem of FSCK, and all interactive features were implemented in a non-interactive manner. Expect is not specifically designed for FSck, which can also perform errors such like FTP.
FSCK and FTP issues show us the limitations of user interfaces provided by SH, CSH and other shells. Shell does not provide a function written from a program and like a program. This means that shell can run FSCK but can only cost the flexibility to sacrifice some FSCK. There are some programs that cannot be executed at all. For example, if there is no user interface interactive, it is impossible to run. Others are like Telnet, Crypt, Su, Rlogin, etc. cannot be automatically executed in the shell script. There are still many other applications that are designed to require users to enter. Expect is designed to interact with a special pin and interactive program. A Expect programmer can write a script to describe the program and the user's conversation. The EXPECT program then can run "interactive" program that is not interactive. The script of the write interactive program is as simple as the script written by the non-interactive program. Expect can also be used to automate a part of the dialogue because the program's control can be switched between the keyboard and the script.
BES [2] has a detailed description. Simply put, the script is written in an explanatory language. (There are also C and C Expect libraries available, but this is outside the scope of this article). EXPECT provides commands that create interactive processes and read and write their inputs and outputs. Expect is named by a command of its same name.
The Expect language is based on TCL. TCL is actually a sub-library that can be embedded in the program to provide language services. The final language is a bit like a typical shell language. There is a set command assigned to the variable, the control program executes if, for, contract, etc., can also perform ordinary math and string operations. Of course, you can also use EXEC to call UNIX programs. All of these features, TCLs have. TCL has a detailed description in the reference book OuterHour [3] [4].
Expect is created on a TCL basis, and it also provides some commands that TCLs. The spawn command activates a UNIX program to interactively run. The Send command sends a string to the process. The expect command waits some string of the process. EXPECT supports regular expressions and can wait for multiple strings at the same time and perform different operations for each string. Expect can also understand some special circumstances, such as timeout and experience in the end.
The style of the expect command and the TCL's case command is very similar. Both use a string to match multiple strings. (As long as it is possible, the new command always is similar to the existing TCL command to keep the language of the instrument's inheritance). The following is an excerpt from the manual [5].
EXPECT PATLIST1 Action1 PATLIST2 Action2 .....
This command has been waited until the output of the current process is matched, or the time exceeds a specific time length, or waits until the end of the file.
If the last action is empty, you can omit it.
Each PATLIST consists of a schema or schema table (LISTS). If there is a mode matching success, the corresponding Action is executed. The result of the execution returns from Expect.
Accurately matched strings (or when the timeout occurs, the string that has been read but not matched) is stored inside the variable expect_match. If PATLIST is EOF or TIMEOUT, the file ends or timeout will perform the corresponding action. General timeout is 10 seconds, but the timeout value is set to 30 when the command similar to "SET TIMEOUT 30" is used. second.
One of the following sections is taken from a script for logging in. Abort is a process defined at the other of the script, while other Actions use TCL primitives similar to C language.
EXPECT "* Welcome *" BREAK
"* busy *" {print busy; continue}
"* failed *" Abort
Timeout Abort
The mode is a regular expression of the usual C shell style. The mode must match all the outputs from the current process from the previous Expect or Interact (very universally used). However, once the output exceeds 2000 bytes, the front characters will be forgotten, which can be changed by setting the value of Match_max. The Expect command does reflect the best and worst nature of the Expect language. In particular, the flexibility of the Expect command is to consulate in confusing syntax. In addition to keyword modes (such as EOF, TIMEOUT), those mode tables can include multiple modes. This guarantees a way to distinguish them. However, separate scans are separately scanned. If there is no proper use ["], this may make and be used as a blank character. Since the TCL provides two string references: single quadrature and double quotation Worse. (In Tcl, if you don't have erriness, there is no need to use quotation). In the manual of Expect, there is an independent part to explain this complexity. Fortunately: there are some very A good example seems to stop this complaint. However, this complexity is likely to appear again in the future version. In order to enhance readability, in this article, the provided scripts are assumed to be sufficient.
The characters can be used separately with a backslash, and the backslash is also used to continue the statement. If the words are not added, the statement is over the end of the row. This is also consistent with TCL. TCL will continue to scan when discovering a single quotes or open trim numbers. Moreover, the semicolon can be used to split a plurality of statements in a row. This is a bit confusing, but this is the style of explanatory language, but this is indeed a less beautiful part of TCL.
5. [Callback]
Surprisingly, some small scripts produce some useful features. Below is a script for dialing the phone number. He used to reverse the charges in order to make long-distance calls. This script is activated with "Expect Callback.exp 12016442332". Where the script is called Callback.exp, but 1 (201) 644-2332 is the phone number to be dial.
#first Give The User Some Time To Logout
EXEC SLEP 4
Spawn Tip Modem
EXPECT "* connection *"
Send "ATD [INDEX $ ARGV 1]"
#modem takes a while to connect
Set Timeout 60
EXPECT "* connection *"
The first line is a comment, the second line shows how to call the Unix program that is not interactive. Sleep 4 will cause the program to block 4 seconds to make the user have time to exit because MODEM always calls the phone number that the user has used.
The spawn command is used under one line to activate the TIP program so that the output of TIP can be read by Expect such that TIP can read from Send. Once TIP says it has been connected, MODEM will ask for a big brother phone number. (Assuming that MODEM is compatible, this script can be easily modified to adapt to other types of modems). No matter what happens, Expect will terminate. If the call fails, the Expect script can be designed to make a retry, but there is no. If the call is successful, getty will detect DTR after expect exit and prompt the user :. (Practical scripts often provide more error detection).
This script shows the use of command line parameters, and the command line parameter is stored in a table called Argv (this and the C language style is very like). In this case, the first element is a telephone number. Square brackets make the partially implemented as a command, and the result is replaced. This is also very like C shell style. This script is similar to the functionality of approximately 60K C language programs.
6. [Passwd and Consistency Check]
In front, we mentioned that the Passwd program cannot run in the absence of user interaction, the passwd will ignore the I / O redirect, nor can it be embedded in the pipe to read input from other programs or files. This program adheres to the truly interaction with the user. Because of the reason, Passwd is designed such that the results result in non-interactive ways to test the passwd. Such a program that is critical to system security has no way to conduct a reliable inspection, and true ironic.
Passwd inputs a password with a username as a parameter. The following EXPECT scripts are used as the user name and password as a parameter rather than interactive operation.
SPAWN OASSWD [INDEX $ ARGV 1]
Set Password [INDEX $ Argv 2]
Expect "* password:"
Send "$ Password"
Expect "* password:"
Send "$ Password"
Expect eof
The first line starts the Passwd program by the user name, for convenience, the second line saves the password into a variable. Similar to Shell, the use of variables does not require ahead of schedule.
In the third line, Expect search mode "* password:", where * allows matching any input, so it is very effective for avoiding all details. There is no action in the above program, so it will continue to run after the mode is detected.
Once the prompt is received, the next line will give the password to the current process. Indicates the Enter. (In fact, all C's conventions are supported). There are two Expect-Send sequences in the above program, because passwd requires two input inputs in order to confirm the input. In the non-interactive program, this is not necessary, but because the passwd is interacting with the user, our script is still doing so.
Finally, the role of "Expect EOF" is to search for file end characters in the output of Passwd, which also shows the matching of keywords. Another keyword match is Timeout, TIMEOUT is used to indicate all matching failures and match a specific length time. Here EOF is very necessary, because Passwd is designed to check all I / O to be successful, including the last new line generated when the password is entered the password.
This script is sufficient to show the basic interaction of the passwd command. Another more complete example back to check some behaviors. For example, the following scripts can check several aspects of the Passwd program. All tips have been checked. Check the garbage input also has appropriate processing. Process death, unusual slow response, or other non-expected behavior has been processed.
SPAWN Passwd [INDEX $ ARGV 1]
EXPECT EOF {EXIT 1}
Timeout {EXIT 2}
"* No such user. *" {EXIT 3}
"* New Password:"
Send "[INDEX $ ARGV 2"
EXPECT EOF {EXIT 4}
Timeout {EXIT 2}
"* Password Too long *" {exit 5} "* password to short *" {exit 5}
"* Retype EW Password:"
Send "[INDEX $ ARGV 3]"
EXPECT TIMEOUT {EXIT 2}
"* Mismatch *" {exit 6}
"* Password unchanged *" {exit 7}
""
EXPECT TIMEOUT {EXIT 2}
"*" {EXIT 6}
EOF
This script exits with a number to indicate the situation. 0 indicates that the Passwd program is running normally, and 1 means non-expected death, 2 indicates locking, and so on. Using numbers is for simple start. EXPECT returns a string and the number of numbers is the same, even if the message itself generated by the derived program is also the same. In fact, the typical approach is to save the entire interaction process to a file, and only the file is deleted when the program is running and expected. Otherwise, this log is left further after further examination.
This Passwd check script is designed to drive by other scripts. This second script reads parameters and expected results from a file. For each input parameter set, it calls the first script and compares the results and expected results. (Because this task is non-interactive, an ordinary old-fashioned shell can be used to explain the second script). For example, a passwd data file is likely to be like the following.
Passwd.exp 3 bogus -
Passwd.exp 0 Fred AableDabl 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 domain is an exit value that needs to match the result. The third domain is the username. The fourth domain and the fifth domain are the passwords that should be entered when prompted. The reduction is only a domain there, and this domain is actually unused. In the first line, Bogus means that the username is illegal, so the passwd will respond: no this user. Expect will return 3,3 when exiting is the second domain. In the last row, ^ c is a practical delivery program to verify that the program is properly exited.
In this way, Expect can be used to verify and debug interactive software, which is precisely the consistency inspection of the IEEE POSIX 1003.2 (Shell and Tool). Please refer to Libes [6] for further description.
7. [Rogue and Pseudo Terminal]
UNIX users are very familiar with the way to connect through the pipeline and other processes (such as: a shell pipeline). Expect uses a pseudo terminal to contact the derived process. The pseudo terminal provides the terminal semantics for the program to think that they are in a true terminal for I / O operations.
For example, the BSD's adventure game Rogue is running in the studio mode and assumes that the other end of the connection is an addressable character terminal. You can program with Expect so that this game can be played by using the user interface.
Rogue This Adventure Game first provides you with a variety of physical properties, such as the role of strength, and In most of the time, the power value is 16, but there will be a power value in almost 20 times. Many Rogue players know this, but no one is willing to start the program 20 times to get a good configuration. The following scripts will reach this. FOR {} {1} {} {
Spawn Rogue
EXPECT "* STR: 18 *" BREAK
"* STR: 16 *"
Close
Wait
}
interact
The first line is a for loop, and the control format of the C language is very like. After Rogue starts, Expect checks that the power value is 18 or 16, if it is 16, the program exits by executing Close and Wait. The roles of these two commands are closing and pseudo-end connectivity and wait for the process to exit. Rogue is read to a file end of the file, so that the loop continues to run, generate a new Rogue game to check.
When a value of 18 is found, the control will launch a loop and jump to the last line script. Interact Transfer control to the user so that they can play this specific game.
Imagine this script run. What you can really see is 20 or 30 initial configurations in less than a second time, and finally left you is a game with a good configuration. The only way to be better than this is to use the debug tool to play games.
We need to recognize this: Rogue is a graphic game using the cursor. The Expect programmer must understand that the cursor movement does not necessarily be embodied in an intuitive manner. Fortunately, in our example, this is not a problem. The future improvements to Expect may include an embedded terminal simulator that supports the character graphics area.
8. [FTP]
We used Expect to write the first script and did not print out "Hello, World". In fact, it achieves some more useful features. It runs FTP by non-interaction. FTP is a program for file transfer on a network that supports TCP / IP. In addition to some simple features, general implementations require users to participate.
The following script removes a file from a host using anonymous FTP. Where the host name is the first parameter. The file name is the second parameter.
Spawn FTP [INDEX $ Argv 1]
EXPECT "* Name *"
Send "anonymous"
EXPECT "* password: *"
Send [exec whoami]
EXPECT "* ok * ftp> *"
Send "Get [INDEX $ ARGV 2]"
EXPECT "* ftp> *"
The above program is designed to perform FTP in the background. Although they use the underlying and Expect mechanism, their programmable ability is reopened. Because Expect provides advanced languages, you can modify it to meet your specific needs. For example, you can add the following features:
: Persistence - If the connection or transmission fails, you can do it every minute or hour.
It can be performed in accordance with other factors, such as the user's load,
Retry.
: Notification - You can notify you through mail, write or other programs when transferring, or even
You can notify it.
: Initialization - Each user can have its own initialization file written in advanced languages
(For example, .ftprc). This is similar to the use of C shell to .cshrc.
EXPECT can also perform 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 a database that describes files obtained by anonymous FTP on the Internet. By using this service, the script can ask the location of ARchie a particular file and take it from the FTP server. The implementation of this feature requires only a few lines in the script above. There is no known background-FTP now to implement the above features, you can not say all the features. It is very simple in Expect. "Adhere" is required to add a loop in the Expect script. Realization of Notifications As long as Mail and Write are already. The implementation of "Initialization File" can use a command, source .ftprc, you can have any expect commands in .ftprc.
Although these features can be plus hook functions in existing programs, this cannot guarantee that each person's request can be met. The only way to provide guarantees is to provide a universal language. A good solution is to integrate TCL itself into the ftp and other programs. In fact, this is the original intention of TCL. Before do not do this, Expect provides a solution that can implement most of the features but does not require any rewritten.
9. [fsck]
FSCK is another example of lack sufficient user interface. FSCK has little way to answer some questions in advance. What you can do is to answer "Yes" to all questions or answer "no".
The following block shows how the automatic automatic automatic answer to some questions answer "Yes", and answers "NO" for some questions. The following script begins to derive the FSCK process first, then answer "Yes" on both types of questions, and answer "no" for other questions.
FOR {} {1} {} {
EXPECT
Eof Break
"* Unref file * clear?" {Send "r"}
"* Bad inode * fix?" {Send "y"}
"*?" {Send "n"}
}
In the following version, the answer to both questions is different. Moreover, if the script encounters what it can't understand, the interact command will be executed to the user. The user's hit is directly handed over to FSCK processing. When executed, the user can quit or return the control to Expect by pressing the " " button. If the control is returned to the script, the script will automatically control the remainder of the process.
FOR {} {1} {} {
EXPECT
Eof Break
"* Unref file * clean?" {Send "y"}
"* Bad inode * fix?" {Send "y"}
"*?" {Interact }
}
If there is no Expect, FSCK can only be run in mutual operation if it sacrifies certain functions. FSck is almost unpalatable, but it is the most important tool for system management. The user interface of many other tools is also the same. In fact, it is the shortcomings of some of the procedures, resulting in the birth of Expect.
10. [Control multiple processes: job control]
Expect's job control concept avoids usual implementation difficulties. These include two problems: one is how Expect handles classic job control, that is, how the expect is handed when you press the ^ z button; another one is how to handle multi-process.
Processing to the first question is: Ignore it. EXPECT does not know anything about classic job control. For example, you have derived a program and send a ^ z to it, it will stop (this is the perfection of the fake end) and the expect will wait forever. However, in fact, this is not a problem. For an Expect script, there is no need to send ^ z to the process. That is, there is no need to stop a process. EXPECT simply ignoring a process, and transferred your attention to other places. This is the work control idea of Expect, this idea has always worked very well.
From the perspective of the user, it is like this: When a process starts through the spawn command, the variable spawn_id is set into a descriptor of a process. The process described by spawn_id is considered to be the current process. (This descriptor is precisely a descriptor of a pseudo terminal file, although the user treats it as an opaque object). The Expect and Send commands interact with the current process. Therefore, switching a job is only assigned to spawn_id of the description of the process.
One example has shown to we show us how to interact between two Chess processes through job control. After derived two processes, a process is notified first step. In the following cycle, each step is given to another process. Among them, the two processes of READ_MOVE and WRITE_MOVE are left to the reader. (In fact, their implementation is very easy, but because it is too long, it is not included here).
Spawn chess; # start player one
SET ID1 $ SPAWN_ID
EXPECT "chess"
Send "first"; # force it to go first
Read_move
Spawn chass; # start player two
SET ID2 $ SPAWN_ID
EXPECT "chess"
FOR {} {1} {} {
Send_move
Read_move
SET SPAWN_ID $ ID1
Send_move
Read_move
SET SPAWN_ID $ ID2
}
There are some applications and chess programs that are not only the same, in the check program, the two players flow. Below this script implements a preferences. It can control a terminal so that users can log in and normal. However, once the system prompts to enter a password or enter the username, Expect begins to mark the hit down, until the user presses the Enter key. This effectively collects the user's password and username, and avoids the "incorrect password-tryagain" of ordinary pre-programs. Moreover, if the user is connected to another host, the additional logins will be recorded.
Spawn tip / dev / tty17; # Open connection to
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 in $ {{
SET SPAWN_ID $ LOGIN
EXPECT
{"* password *" "* login *"} {
Send_user $ evECT_MATCH
SET LOG 1
}
"*"; # Ignore everything else
SET SPAWN_ID $ TTY;
Send $ evct_match
}
Case $ TTY IN $ {{
SET SPAWN_ID $ TTY
EXPECT "* *" {
IF $ log {
Send_user $ evECT_MATCH
SET LOG 0
}
}
"*" {
Send_user $ evECT_MATCH
}
SET SPAWN_ID $ login;
Send $ evct_match
}
}
This script works this. First connect to a login process and terminal. By default, all dialogues are recorded on standard output (via Send_user). Because we are not interested in this, we ban this feature through the command "log_user 0". (There are a lot of commands to control things that can be seen or can record).
In the loop, the SELECT is waiting for the terminal or the action on the Login process, and returns a spawn_id table waiting for input. If you find a value in the table, CASE executes an action. For example, if the string "login" appears in the output of the Login process, the prompt will be recorded on the standard output, and there is a flag to be set to notify the script to start recording the user's hit button until the user presses the Enter. key. Regardless of whether it is received, it will return to the terminal, and a corresponding Action will execute at the end of the script.
These examples show how the EXPECT work control method. By plugging yourself into the dialogue, Expect can create complex I / O streams between processes. You can create a multi-fan, multiplexed fan-in, dynamic data related procedures.
In contrast, shell makes it difficult to read a document in one line. Shell forces users to press the control key (such as, ^ c, ^ z) and keywords (such as FG and BG) to switch. These cannot be utilized from scripts. Similar: the shell running in non-interactive manner does not address "history" and other features that are only interactive. This also appears similar problems with which Passwd program in front. Similar, it is impossible to write a shell script that can return to some actions of the test shell. As a result, these aspects of the shell cannot be thoroughly tested.
If you use Expect, you can use its interactive job control to drive the Shell. A derived shell considers that it is running in interaction, so it will process job control. It not only solves the problem of testing the shell and other programs that control the work control. It is also possible to let the shell will handle your job when necessary. You can support the operation of the process to support the process of operation using the shell style. This means: first derive a shell, then give the command to the shell to start the process. If the process is suspended, for example, a process will stop, and return the control to the shell. For Expect, it is still handling the same process (original shell).
The EXPECT solution not only has great flexibility, but it also avoids the job control software that has been repeated in the shell. By using the shell, since you can choose the shell you want to derive, you can get job control rights as needed. Moreover, once you need (for example, when you are tested), you can drive a shell to let this shell think it is running interactive. This is also important for programs that change the output of the output after the interactive run is detected.
For further control, during Interact execution, Expect sets the control terminal (which is the terminal that starts the expect, instead of the pseudo terminal) to generate the formation mode so that the characters can be properly transmitted to the derived process. When EXPECT does not perform Interact, the terminal is in a familiar mode, at this time, the job control can act on the Expect itself. 11. [Interactive Use EXPECT]
In front, we mentioned the use script that can be interactive through the interact command. Basically, the interact command provides free access to the conversation, but we need some more fine control. This, we can also use Expect to reach because EXPECT reads input from the standard input and is as simple as read from the process. However, we have to use Expect_user and send_user to perform standard I / O while do not change the spawn_id.
The following script reads a line from the standard input within a certain time. This script is called TIMED_READ, which can be called from CSH, for example, set answer = "timed_read 30" can call it.
#! / usr / local / bin / evect -f
Set Timeout [INDEX $ Argv 1]
EXPECT_USER "*"
Send_user $ evECT_MATCH
The third line receives any row that ends with the new line. The last line returns it to the standard output. If you do not get any typing within a specific time, it is also empty.
The first line supports the "#!" System direct startup script. (If you add an attribute of the script plus the executable properties, don't add Expect to your script. Of course, the script can always be explicitly started with "expect scripot". Options later in -c are executed before any scripting statement is executed. For example, do not modify the script itself, add -c "trace ..." on the command line, which can be added to the Trace function (the optional number indicates the option of TRACE).
In the command line, you can actually add multiple commands, as long as the middle is ";" it can be separated. For example, the following command line:
EXPECT-C "SET TIMEOUT 20; Spawn foo; Expect"
Once you set the timeout time limit and after the program starts, the expect starts waiting for the file ending or 20 seconds timeout time limit. If the file end value (EOF) is encountered, the program will stop, then Expect returns. If it is a timeout, Expect returns. In these two mid situations, all implicitly killed the current process.
If we don't use EXPECT to implement the functions of the above two examples, we can still learn a lot of things. In these two mid situations, the usual solutions are the child process for Fork another sleep and inform the original shell with Signal. If this process is or read first, the shell will kill the process of sleep. Passing the PID and prevents the background process to generate startup information is a headache that makes a headache except the master shell programmer. Providing a generic method is like this to start multiple processes so that the shell script is very complicated. So it is almost certain that programmers usually use a special C program to solve such a problem.
Expect_user, send_user, send_error (output to standard Error Terminal) In the relatively long, it is used to use the complex interactive translation of the process into simple interaction. In the reference [7], Libs describes how to use the script security package (WRAP) ADB, how to free the system administrator from the need to master the details of the ADB, and greatly reduce the system caused by the wrong hit button. collapse.
A simple example enables FTP to automatically take files from a private account. In this case, a password is required. Even if the file is accessed, you should also avoid storing the password in a clear text. The parameters when the password is run as a script is also inappropriate because they can be seen with the PS command. There is a solution that is to invoke Expect_user to start the script to allow the user to enter the password that may be used later. This password must only let this script know, even if you are every hour, try the FTP. Even if the information is ready to enter, this skill is also very useful. For example, you can write a script, change the password on each of your hosts, no matter whether they are using the same password database. If you have to reach such a feature, you must Telnet to each host and manually entered the new password. And use Expect, you can only enter your password once and let the script do other things.
Expect_user and interact can also be used in a script. Considering the situation that after the cycle of debugging a program, after a multi-step, it will fail. Which debugger can be driven, set a breakpoint, execute the sever of the program loop, and then return the control to the keyboard. It can also be switched back and forth between the cyclic body and condition test before returning.
