Xref: utzoo alt.sys.sun:813 comp.unix.wizards:21817
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!lwall
From: lwall@jato.Jpl.Nasa.Gov (Larry Wall)
Newsgroups: alt.sys.sun,comp.unix.wizards
Subject: Re: Scripts that talk across telnet?
Message-ID: <3593@jato.Jpl.Nasa.Gov>
Date: 4 May 90 23:56:07 GMT
References: <2782@husc6.harvard.edu>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 28

In article <2782@husc6.harvard.edu> bochner@speed.harvard.EDU (Harry Bochner) writes:
: It looks like perl would be a good language for writing a script that
: scans the responses and determines whether they look normal. The problem
: is that my preliminary experiments seem to indicate that telnet doesn't
: like to talk to scripts: I tried a simple script that just pipes output
: to telnet, and it tells me "Connection closed by foreign host" without
: doing anything else.

You don't want to talk to telnet, you want to talk to the telnet socket
on the other machine.  You can just open up a socket in perl and connect
directly to the other machine.  For a sample, look at the client in the
perl man page.  You might need to use send and recv instead of the line
oriented stuff, but it's the same general idea.

: The best scheme I've been able to think of is to write a C pgm that opens
: a pseudo-terminal, and then starts perl on the master side, and telnet on
: the slave side. Will this work? Any better ideas?

You could do that too.  Somebody posted the requisite perl routines to
open a pty not long ago in comp.lang.perl.  Someone could dredge those up for
you if you like.

But there's little reason not to talk directly to a foreign socket.  The
telnet daemon on the other end will put a little trash out at the beginning,
but it's easily ignored.

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov