posted by Mikhail E. Zakharov on Tue 21st Jun 2005 17:26 UTC
IconLike it or not, but sooner or later you realize that you'll have to write shell-scripts to administer UNIX. And among these scripts there certainly will be those to cooperate with interactive applications such as telnet, ftp, su, password, ssh. But it means the end of the admin's quiet life because while dealing with interactive programs one often come across numerous hidden traps which doesn't usually happen with ordinary sh-scripts. Though fortunately or may be not, but most of these problems generally turn up within first five minutes of the work under the script. The symptoms typically look like that author can't pass the authentication from the script. At first you feel confused because usual pipe constructions such as:

$ echo luser && echo TopSecret | telnet

fail you and the problem which seemed so plain on the face of it grows into "mission impossible". Yet, it isn't all so very hopeless and quite a simple solution of the problem will come quickly enough for many of the dialogue applications include built-in mechanisms of handling scripts. See, for example, standard FreeBSD ftp-client:

$ echo '$FILEPUT' | ftp -N ftprc

This command will get ftp to connect with the hosh with the name of luser and start FILEPUT macro described in the file ftprc. Besides the macro there must be also described the host, the login and user's password in this file:

$ cat ftprc
	login luser
	password TopSecret

macdef FILEPUT
	cd /tmp
	put some_usefull_file.bin
		<-- Attention! There is a new-line symbol at the end of the macro.

If for some reason the dialogue application doesn't support the built-in scripts then you'll easily find it's freeware counterpart capable to act automatically. Really you are not the first to run into such a problem :-)

Another possibility to persuade an interactive program to do work by itself, without a user, is to redirect its standard input. For example, much simplified script to start Oracle database may look like this:


su - oracle - /oracle/bin/svrmgrl <

Yet we can't work like that with all kinds of applications. For instance, it isn't suitable for telnet, through the "problem of user's authentication" mentioned above. The difficulty to debug scripts at the moment of authentication complicates matters. So, it's clear that to find the way out we need some special solution. Let's don't break good traditions and google the Internet. Going through different search systems brings us some fruits in the form of indistinct mumbling about the untimely closed I/O data streams, TTYs and PTYs (pseudoterminals) and all the rest of it. But in all this incongruous abundance you'll certanly find the links to


It's just what is wanted: the tool, which is traditionally used to communicate automatically with interactive programs. And as it always occurs, there is unfortunately a little fault in it: expect needs the programming language TCL to be present. Nevertheless if it doesn't discourage you to install and learn one more, though very powerful language, then you can stop your search, because expect and TCL with or without TK have everything and even more for you to write scripts.

If there is no expect installed in your system you should install it. On FreeBSD you'd better do it by using port-system:

# cd /usr/ports/lang/expect
# make install clean

As a result expect and all it needs will be downloaded from the Internet and installed on your system.

Now we can work with the TCL and expect. As for the problem of intercative programs, the expect-script for a short telnet-session with host (let it be SCO UnixWare-7.1.3), under login of luser with password TopSecret can look like that:


spawn telnet
expect ogin {send luser\r}
expect assword {send TopSecret\r}
send "who am i\r"
send "exit\r"
expect eof

By the way, the README file of the expect says there is a libexpect library that can be used to write programs on C/C++ which allows to avoid the use of TCL itself. But I'm afraid, this subject is beyond this article. Besides authors of expect themselves seem to prefer expect-scripts to the library.

Table of contents
  1. "Unix scripts, Page 1/4"
  2. "Unix scripts, Page 2/4"
  3. "Unix scripts, Page 3/4"
  4. "Unix scripts, Page 4/4"
e p (0)    22 Comment(s)

Technology White Papers

See More