OSNews

$ echo luser && echo TopSecret | telnet foo.bar.com

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 luser@foo.bar.com

This command will get ftp to connect with the foo.bar.com 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
machine foo.bar.com
	login luser
	password TopSecret

macdef FILEPUT
	binary
	cd /tmp
	put some_usefull_file.bin
	bye
		<-- 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:

#!/bin/sh

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

expect

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 foo.bar.com (let it be SCO
UnixWare-7.1.3), under login of luser with password TopSecret

can look like that:

#!/usr/bin/expect

spawn telnet foo.bar.com
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

"Unix scripts, Page 1/4"
"Unix scripts, Page 2/4"
"Unix scripts, Page 3/4"
"Unix scripts, Page 4/4"