[SGVLUG] Automating (scripting) telnet

[Emerson, Tom]

> -----Original Message-----
> Behalf Of DJ Byrne
> On Tuesday, February 21, 2006, at 02:28  PM, Emerson, Tom wrote:
> 
> > I have a small fetchmail problem.
[which results in several messages queued on the server]

> > What I'd like to do is somehow "script" telent so that I can delete 
> > those 600+ messages that have already been processed, 
> >
> > If I just "feed" this to telnet, i.e., "telnet <cmds", it 
> doesn't work 
> 
> You've already noted that "expect" is the Right Way,
> but did you try a simple sh script "here document?"
> 
> telnet <my.providers.pop.server> pop3 < EOF

this isn't any different than "cat cmds | telnet" or "telnet < cmds" (and just to be clear, a "here document" uses a double "<", at least, according to the website I checked...)

But... here's one to file in the "learn something every day" catagory -- in looking up some docs to check on the need for << vs. <, if you do something like this:

   myprog <<-EOF
           input line 1
           input line 2
           etc.
   EOF

where the leading "whitespace" consists of TAB characters, then the tab characters are stripped from the input (just the leading tabs though -- leading spaces and embedded tabs are preserved...)

> Hmm; alternatively, here's an example showing
> throttled cmds to telnet ...
> 
> #!/bin/sh
> 
> {
> echo helo
> sleep 2
> echo vrfy
> sleep 2
> echo quit
> sleep 2
> } | telnet localhost 25

The problem is still flow-control.  I've noted the response time to the "pass" command is anywhere from immediate to 5 seconds or more (usually slanted to the 5-second side, it seems...)  once past that point, however, response time tends to be immediate but it still isn't guaranteed.  Delaying for an arbitrary 1 or 2 seconds may do the trick, but it could still hiccup every now and then...

On the mini/mainframe I use here at work (the HP3000), the I/O system sends a "read trigger" [DC1] at the end of the prompt -- the "terminal" knows this and can hold back any input until it sees this character from the "remote" end of the connection.  (the folks that wrote terminal emulators used this fact to create a client-side typeahead capability)