expect question

[john heasley]

Wed, Jul 23, 2003 at 11:59:24AM -0700, 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.

page?  what's the variable you modify to get it to consider it as
part of the next expect (i forget)?

> 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?

shouldnt matter.  i was just looking for escape and/or escap sequences
(curses crap).  expect should read in chars and try to match, or repeat
until match.  \e would never match.  while hpfilter basically does the
same thing, but works.

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

well, rusty on telnet protocol, but is that not dependant upon 7/8 bit
and/or options?  of course, hpfilter only tries to deal with curses
stuff.