Xref: utzoo alt.sys.sun:816 comp.unix.wizards:21825
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: alt.sys.sun,comp.unix.wizards
Subject: Re: Scripts that talk across telnet?
Message-ID: <26910:May511:16:3290@stealth.acf.nyu.edu>
Date: 5 May 90 11:16:32 GMT
References: <2782@husc6.harvard.edu> <3593@jato.Jpl.Nasa.Gov>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Distribution: usa
Organization: IR
Lines: 36

In article <3593@jato.Jpl.Nasa.Gov> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
> In article <2782@husc6.harvard.edu> bochner@speed.harvard.EDU (Harry Bochner) writes:
    [ telnet wants to talk to a terminal ]
> 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.

If you can't get perl to work or if you want security (i.e., knowing the
username on the other side of the connection) you could try my auth
package, which appeared a few days ago in comp.sources.unix.

> : 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.

Or, again if you can't get perl to work or would like some of that
security that's so hard to achieve with BSD ptys, you could wait for my
pty program, to be submitted to comp.sources.unix next week. Then you
just type pty telnet rather than telnet.

> But there's little reason not to talk directly to a foreign socket.

True. But the pty solution gives you control in more general situations.

> The
> telnet daemon on the other end will put a little trash out at the beginning,
> but it's easily ignored.

You shouldn't ignore the trash; you should respond to it as specified in
RFC 854. It's a shame the TELNET protocol didn't make a clean break from
``standard'' ASCII.

---Dan