[comp.unix.questions] expect: redirect output to a pipe

fitz@rpi.edu (Brian Fitzgerald) (02/10/91)

In an "expect" script, can I

...  interact with a spawned process until I type an escape character

...  then redirect the process' output to a PIPE until the process
sends a prompt string

...  then interact with the process again?

(pty answers are welcome, but can this be done with just "expect"?)

Brian Fitzgerald

libes@cme.nist.gov (Don Libes) (02/11/91)

In article <DC*&=6|@rpi.edu> fitz@rpi.edu (Brian Fitzgerald) writes:
>In an "expect" script, can I
>...  interact with a spawned process until I type an escape character
>...  then redirect the process' output to a PIPE until the process
>sends a prompt string
>...  then interact with the process again?

Yes you can.  Please send further questions via mail.

Since you didn't specify them, I've left process, escape, prompt, and
pipe (as file descriptor) as variables.

spawn $process
set proc $spawn_id
interact $escape return
set old {}
set timeout 1
for {} 1 {} {
	set spawn_id $proc
	expect full_buffer
	set spawn_id $pipe
	send $expect_match
	if [string first prompt [format %s%s $old $expect_match]]!=-1 break
	set old $expect_match
}
interact

The interesting part of the script is the "full_buffer" keyword.  It
tells expect to return when its internal buffer is full, rather than
its usual behavior.  You then do the string matching yourself.  The
%s%s handles the case when the prompt straddles two buffers.

timeout is set low because the string matching is done after the
expect and you don't want to hang around waiting for the buffer to
fill if it might not.  You can also set it higher, and add "*$prompt*
break" to the expect command.  It really depends if you can better
characterize your output.

Note that even if you have an early version of expect that doesn't
support "full_buffer", this script will work (albeit doing unnecessary
matching on the unrecognized parameter) unless you have a process that
really screams in which case you want to increase match_max.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes