News Group Posts

kermit vs. expect automating login

One thing that prevented Kermit from gaining more poularity was that it required licensing. Kermit is Open Source as of July 1st, 2011.

From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.unix.sco.misc,alt.os.linux.slackware,comp.os.linux,comp.os.linux.misc
Subject: Re: Running script with telnet
Date: 20 Mar 2000 23:59:13 GMT
Message-ID: <8b6e0h$k0j$1@newsmaster.cc.columbia.edu> 
References: <38D65A06.523CE005@newview.com.br> 

In article <38D65A06.523CE005@newview.com.br>,
Matheus Cunha Torres  <teteu@newview.com.br> wrote:
: Is it possible to telnet another box and run a script from your machine in
: the foreign host. As an example, suppose I want to telnet a pop server
: (telnet foreign.domain.com 110) and automatically delete the messages there
: and log out. It's just an example, I know there are pop reader that can do
: that...
: 
: Is ther any option in telnet that allows me executing the comands after
: conecting?
: 
A very common question, and one which always bring forth a blizzard of
different answers, the most common one being "use expect".  Here's another
perspective, quoting myself from a recent comp.unix.programmer thread:

 From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
 Newsgroups: comp.unix.programmer
 Subject: Re: Telnet
 Date: 10 Mar 2000 23:45:27 GMT
 Organization: Columbia University
 Lines: 75

 In article <38C94BFB.291AD871@gcg.com>, Chuck Dillon <dillon@gcg.com> wrote:
 : ...
 : Another poster already mention this but since you don't know
 : perl now C I'm guessing a vague reference to 'expect' might
 : not stick in your mind.
 : 
 : Expect is a scripting tool that is designed to automated command
 : line interactions via pseudo-terminals.  It should be exactly
 : what you are looking for.  Take a look at http://expect.nist.gov.
 : 
 Expect will normally do the job, but it's not available for as many
 UNIX platforms as C-Kermit, let alone non-UNIX platforms like VMS,
 OS-9, VOS, etc.

 Also there is an intrinsic weakness in the 'expect' approach -- all
 that 'expect' sees is text.  So when automating interactions with some
 other program such as telnet or ftp, the only way to tell whether a
 particular command succeeded or failed is by parsing the response --
 which is notoriously unreliable.  In the case of Telnet, it has no
 way of knowing if the text it's looking at is from the remote host
 or from the local Telnet program.  It's just a stream of text.

 When the scripting language is intrinsic to the Telnet client, it
 knows when a command succeeds or fails because it executed the command
 itself.  When using 'expect' to drive the Telnet program, you have
 to account for various responses:

   $ telnet foo.blah                     <-- Bad hostname
   foo.blah: unknown host
   telnet> 

   $ telnet pc.xyzcorp.com               <-- Host with no telnet server
   Trying 123.123.123.123
   telnet: connect: Connection refused
   telnet>

   $ telnet down.xyzcorp.com             <-- Host is down
   Trying 123.123.123.124 ...
   telnet: connect: Connection timed out
   telnet>

   $ telnet mainframe.xyzcorp.com        <-- Incompatible telnet server
   Trying 123.123.123.125 ...
   Connected to mainframe.xyzcorp.com
   Escape character is '^]'.
   Connection closed by foreign host.

   $ telnet okhost.com                   <-- This one worked
   Welcome to okhost.com, blah blah ...
   login:

 And so on...

 In C-Kermit, this is programmed as follows:

   set host <hostname> /telnet
   if fail (take-desired-action) <-- It doesn't matter what the message is.
   input 10 login:
   if fail ...

 Once the connection is made, of course, you still have to script the remote
 prompts, commands, and responses.  Unless, of course, a Kermit server is
 available on the remote system, in which case you can use client/server
 commands for most common tasks (including file transfer) and skip the
 scripting altogether.

 C-Kermit is at:

   http://www.columbia.edu/kermit/ckermit.html

 Sample telnet and other scripts are at:

   http://www.columbia.edu/kermit/ckscripts.html

 - Frank

(end quote)

From - Mon Aug 14 15:50:03 2000
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.os.linux.misc
Subject: Re: Passing command to Telnet with a text file
Date: 14 Aug 2000 19:26:20 GMT
Message-ID: <8n9h4s$i1j$1@newsmaster.cc.columbia.edu> 
References: <4k6gpsc0pl7tvorrlq0asa0isivqiodcgi@4ax.com> 

In article <4k6gpsc0pl7tvorrlq0asa0isivqiodcgi@4ax.com>,
Richard Lewis  <rlewis@satelliteinfo.co.uk> wrote:
: Is it possible to pass a series of commands to a telnet session from a
: text file? eg. using a command like "telnet <commands.txt", where
: commands.txt would consist of a series of commands.
: 
One way is to use a Telnet client that has its own built-in scripting
language for automation, such as C-Kermit:

  http://www.columbia.edu/kermit/ckermit.html

This has certain advantages over the Telnet/Expect combination which seems
to be the popular knee-jerk reaction to this question:

 . If Expect is used to drive Telnet or Rlogin, it can't tell the 
   difference between local and remote text.

 . Kermit knows whether each command succeeded or failed -- not just
   INPUT ("expect"), but every command -- and can take any desired action
   depending on the success or failure of each command.

 . Expect has no access to the connection itself and so can't tell
   if it's up or down, what state it's in, etc.  For example, on a
   serial connection, Kermit can check for specific modem signals.

 . Expect can't transfer files.

 . Kermit runs on a wider variety of platforms than expect.

Look here:

  http://www.columbia.edu/kermit/ckscripts.html

for sample Kermit scripts.  In particular see "autotelnet" in the Internet
scripts section.

- Frank

Comments?

More Articles by Tony Lawrence

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.