次のようにexpectをインタラクティブに使用すると、うまく機能します。
root@vagrantup:/home/vagrant> expect -i
expect1.1> spawn screen -x
spawn screen -x
3195
expect1.2> send "ls\n"
expect1.3> exit
ただし、ファイルで使用されるのと同じコマンド：
spawn screen -x
send "ls\n"
exit
たまにしか機能しません。ファイルを実行するたびに1/10回。本当に変です。
次のコマンドでファイルを実行します。
expect -f Expectfile
私もこれらをテストしました：
expect -b Expectfile
expect Expectfile
しかし、同じエラーが発生します。
何も言わない。もう一方の画面（「screen」コマンドを使用しているため）は、いつかしか応答しません。誰もが理由を知っていますか？
lsファイルのローカルリストが必要な場合は、コマンドを使用する方がはるかに優れているため、他の何かの代わりに使用していることを願っていますglob。もちろん、あなたは実際にそのようなことをしているかもしれませんが、screen -xそれを使っても、今は少し複雑すぎます。
考えられる障害（証拠がないため、ここでは暗闇で撮影しています）は、仮想端末を使用したさまざまなものの間の相互作用である可能性があります（期待と画面の両方でそれが行われ、システム全体で利用できる仮想端末はそれほど多くありません）または、セッションへの接続を再確立するための十分な時間がないために、ある種のタイミングの問題が発生します。（10回のうち9回失敗しますか？それはたくさんあります。）タイミングの問題である場合は、を挿入するafter 500と役立ちます。それが端末の数である場合、問題があります。のようなツールでこれを見つけることは可能かもしれませんがlsof、可動部品がたくさんあり、何が失敗しているのかわかりません。
なんで？あなたがExpectを誤用しているからです。
スタックオーバーフロースレッドが、Expectについて欠けていることを教えるための効果的な媒体であるとは確信していません。より良い出発点はこれである可能性が高いです：なぜあなたはExpectを使うべきだと思いますか？試みているように見える画面を自動化するには、TclのExpect拡張機能ではなく、コアTclを使用する方がよい場合があります。
画面は素晴らしく、Expectは素晴らしく、私は常に自動化に賛成です。あなたが提示した特定の組み合わせは、保証される可能性があるよりも複雑に聞こえます。