Expect echo problem

[Robert Edin]

Hi
I have a fundamental problem when I'm using Expect that is really
troublesome for my application.

I'm using the telnet program to connect to a another program
that has a server socket. This program takes simple commands.
Example session:

getvalue speed
ok:getvalue speed
speed 50

The first line is the command and the two following are the response.
A simplified version of how I use this from Expect is

spawn telnet $host $port
exp_send "getvalue speed\r"
expect "getvalue speed" ;# Echo of the command
expect "ok:getvalue speed\n"
expect -re "speed (\[0-9]+)\n"

The connected program does also produce spontanious output,
and this is what gives me problem.
The echoes of the commands I send get mixed-up with the
spontanious messages in the input buffer! Assume the
spontanious message is "xxx\n", the input buffer could
look like:

"getvalue spxxx\need\nok:getvalue speed\nspeed 50\n"

I have tried various ways to turn off echo etc. but I
only get confused...

1) Where does the echo of the command sent origin from?
2) How can I turn the command echo off or prevent it from getting
mixed up with spontanious messages from the spawed program?

Thanks in advance,

-- Robert

[Patrick Dunnigan]

My guess would that it is the server on the other end that is doing the echo
and out of the control of the Expect script. Does the remote server echo
these commands back at you when you perform them at a command line? If so,
the Expect program will perform the same way.

However, you migh try setting stty echo to off. But I believe this won't
have an affect on a remote connection.

stty -echo

Have you tried setting exp_internal

set exp_internal 1

This output may provide clues.

"Robert Edin" <rober...@gmail.com> wrote in message
news:be42cce1.0504...@posting.google.com...

[Don Libes]

If your telnet without specifying a port, it is usually the remote
system's terminal driver that does the echoing. If you specify a
port, then the echoing is usually done locally (by telnet itself).
However, there are exceptions.

Personally, I'd skip trying to match the command echo. Instead, just
match the response strings like "ok:"

And if you want the spontaneous messages, use expect_before.

Don

[Robert Edin]

- The server socket I connect to is a simple program on 'localhost'
and does not echo. Also tested with simple programs like "WinSock"
to prove that it does not echo.

- My program is based on that it uses expect_before with several
patterns to match the spontanious messages.
The patterns are anchored to beginning of buffer with '^' to
allow messages to arrive in arbitrary order without discarding
any messages unintentionally (advice from Don, thanks!)

- I have used exp_internal to find out how a spontanious message
is placed in the middle of a echoed command. I try another example
to explain: assume a command "start" is sent to the connected
program with the server socket. The reply should only be "ok:start".
In the input buffer I usually correctly find.

"start\nok:start\n"

Also assume that there is a spontanious message "SPONTANIOUS_MSG"
that can be sent at any time from the connected program.

When the spontanious message gets mixed up with the command echo
in the input buffer it looks like

"staSPONTANIOUS_MSG\nrt\nok:start\n"

This means that my expect before pattern

-re "^SPONTANIOUS_MSG\n"

will fail to find it's message.

So, how can I avoid the echo from getting into the input buffer?

I also tried to avoid the telnet program by using a tcl socket
but it fails when I try "spawn -open".

>expect
expect1.1> socket localhost 5001
sock4
expect1.2> read sock4 10
info: ATP ;# Yes the program is connected!
expect1.3> exp_internal 1
expect1.4> spawn -open sock4
spawn [open ...]
spawn: returns {0}
0
expect1.5> exp_version
5.26
expect1.7> info tclversion
8.4
expect1.8>

I don't understand what goes wrong.
I use Expect on Cygwin, so there is no newer version I think.

-- Robert

[Khaled]

The echo question is simple, when you are using just telnet without
expect, do you see the echo? can you turn it off? if yes, then you'll
be able to do the same thing with expect, if not, then expect cannot.
In other words, expect does not affect or control echoing on remote
connections.

To separate the spontaneous msgs from normal output, you may do the
following:
1. use an [expect_before] to catch the spontaneous msgs. Do this
_without_ anchors! Your "^" anchor requires that a msg arrives first
thing in the buffer which is not the case, since they can arrive any
time mangled with other output.
2. use an [expect] to catch the other output. You'll use one line to
match the last pattern and another to catch anything else. You store
the matched output into a variable, thus reassemblying it again (after
removing the spontaneous msgs).

Here is an example of how to do this:

expect_before {
-re "SPONTANIOUS_MSG_1\[\n\r\]+" {
append msgs $expect_out(buffer)
exp_continue
}
-re "SPONTANIOUS_MSG_2\[\n\r\]+" {
append msgs $expect_out(buffer)
exp_continue
}
-re "SPONTANIOUS_MSG_3\[\n\r\]+" {
append msgs $expect_out(buffer)
exp_continue
}
...
}

spawn telnet $host $port
expect -re "some_prompt.*$" ;# you don't just start to send, do you?
exp_send "getvalue speed\r"
expect {
-re ".*$" {append output $expect_out(buffer)}
-re ".+" {
append output $expect_out(buffer)
exp_continue
}
}

Now you have two separated output stored into two separate variables:
1. "msgs" contains the spontaneous msgs
2. "output" contains all other output

HTH !
Rgrds,
Khaled

[Robert Edin]

It's unfortunally not possiby, as far as I understand, to avoid the
anchoring.
If a second spontanious messages arrive before the first is consumed,
and that is the case for me, there will be problems.
Example inbut buffer content:

"SPONTANIOUS_MSG_2\nSPONTANIOUS_MSG_1\n"

In the next expect call the first pattern in your example will match
SPONTANIOUS_MSG_1 and SPONTANIOUS_MSG_2 is discarded.

[Khaled]

If so, group these msgs in one statement,

expect_before {
-re "(Msg1|Msg2|Msg3|...)\[\r\n]+" {
append msgs $expect_out(buffer)
exp_continue
}
}

Rgrds,
Khaled

[Robert Edin]

Yes, that could be a way to solve it!
I'll only have to figure out how to "connect" the right action
to each message again in my code. But that is "only work" :-)

Thanx, Robert