bochner@speed.harvard.EDU (Harry Bochner) (05/04/90)
I have a routine task that involves ftp'ing a file from a sun4 to an IBM CMS machine, then logging into that machine via telnet, massaging the file and then transmitting it to another user using the CMS 'sendfile' command. I'd like to write a script to automate this, ideally a smart script that runs silently if everything goes smoothly but that passes back any error messages. Is there a scripting utility available that can do this? 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. 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? Harry Bochner bochner@endor.harvard.edu
lwall@jato.Jpl.Nasa.Gov (Larry Wall) (05/05/90)
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.govbrnstnd@stealth.acf.nyu.edu (05/05/90)
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