The titular quote is something newcomers to Expect often say--as one of Expect's frequently-made mistakes, it indicates a misconception or two.

This explanation deserves its own Wiki page: Expect is organized in terms of a dialogue. It does not have a direct notion of "the content of the previous send"; instead, we all have the expectation that, after a command is sent, what appears before the next prompt is the result of that command. That's a convention, though. From Expect's perspective, it's all just characters going back and forth, with no privileged concept of "command", "prompt", or so on.

Let's do a simple example: what do you expect from

    set prompt {$ }

    spawn ssh $user@$host
    expect "Password: "
    send $password\r
    expect $prompt
    send ls\r
    puts "The output is '$expect_out(buffer)'."

? You'll probably see something like the $host logon message.

To achieve what people think they want, it's necessary to write instead

    spawn ssh $user@$host
    expect "Password: "
    send $password\r
    expect $prompt
    send ls\r
    expect $prompt
    puts "The output is '$expect_out(buffer)'."

Do you see the difference?

---

It's sometimes useful to

    expect *            ; # Receive *anything* returned immediately.

My experience has been this is hardly ever useful - it means "match on anything - including nothing" and usually returns nothing. But it does it very quickly. RJ

and/or

    expect timeout      ; # Receive everything returned up to $timeout seconds.

when one "just wants the answer".

Also, note that $expect_out(buffer) doesn't really hold what people want; it typically needs to be filtered down at least to eliminate the prompt.

Also be aware of the "match_max <max buffer size>" expect buffer size. if you do not get all the response you expect then you should probably increase the size.

---

"How to access the result of a remote command in Expect" makes somewhat different computations to achieve similar results.

---