The titular quote is something newcomers to [Expect] often say--it's 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 " expect buffer size. if you do not get all the response you expect then you should probably increate the size. ---- "[How to access the result of a remote command in Expect]" makes somewhat different computations to achieve simlar results. ---- [Category Expect]