expect question

[Richard Threadgill]

In message <20030723185146.GN1334 at shrubbery.net>john heasley writes
>Wed, Jul 23, 2003 at 09:32:32PM +1000, Andrew Fort:
>> A question for the expect clueful lurking..
>> 
>> Can one perform a regsub on the data returning from the telnet/ssh/etc 
>> session? 
>> I'd like to escape out an RE of terminal control characters that are 
>> intermingled in the stream before being passed to the expect clause.
>> 
>
>i do not know of any way to do this.  ultimately,
>
>	expect_before {
>		"esc-match"	{ rewrite_w/o
>				  push back
>				  exp_continue
>				}
>	}
>
>afaik, your only option is to match the curses junk, strip it, and continue.
>
>when working on hrancid, i could not get this to work properly.  i bagged
>it and hence hpfilter.

Yeah, that's what's supposed to work.  I've used it once or twice in
some extreme cases with some other tcl apps, but its tricky.  The
O'Reilly tcl book actually gives an example of doing basically
this, but I haven't had a chance to look at the rancid code at
where it would need to be shoe-horned in.

John - was there any chance that the reason things weren't
working were that you weren't in the line mode you thought you
were in?  Or that you were trying to trap control chars when you
needed to be trying to trap telnet glyphs?

One of the nasty things we encountered while working
with delivery drivers for Ponte was that we needed more of telnet
in the driver than we expected, to deal with session backup, and
disconnect, etc - basically, we (programmers) always were
thinking about the session as being in line mode when in fact its
in character mode.  This normally doesn't matter, but when you're
trying to strip out terminal control noise it becomes really
important.  Also, keep in mind that in many circumstances the
human is thinking 'and now the terminal is sending a <Ctrl-C>
when what's actually happening is that the far end is sending a
telnet protocol-glyph for <Interrupt-char> and the expect session
is recieving that glyph instead of <ctrl-c>.

RichardT