expect轉義符及遠端主機執行命令

expect-send對：expect等待輸出並判定特定的字元，通常是提示符，當字元匹配，則send下一步的操作；若字元與expect期望的輸出不乙隻時，往往會報錯退出。expect不支援太複雜的命令，一般都是按照既定的返回執行下一步的操作，比較呆板，但很多時候還是很有用的

在命令send時，往往有寫特殊字元需要進行轉義：

1.」對應轉義字元： \\\」

2.[ 對應轉義字元： [

3.} 對應轉義字元： }

4.$ 對應轉義字元： \\\$

5.\ 對應轉義字元： \\\

6.` 對應轉義字元： \`

最近由於有大批量的任務需要在不同的主機上進行執行，使用過程中，偶爾會出現expect: spawn id exp6 not open的報錯，一直以為是超時的問題，但是set timeout -1 禁止超時後，仍然會出現報錯

問題分析結果：

經過分析，發現是偶爾已一兩台主機的命令列提示符不一致；不一致的原因在於命令提示符有的主機沒有空格，大多數主機是預設有空格的。

問題解決：

expect支援if判斷，但是對於根據expect的返回結果來進行判斷，對於這種簡單的互動過程是不現實的。所以最好是能夠將命令提示符進行統一，即開始expect，統一設定ps1的格式，最後問題解決。

事例**如下：

#!/usr/bin/expect

#這裡ip可以設定成輸入變數，便於批量執行

set ipaddr "localhost"

#設定登入的使用者名稱和密碼；需要有登入許可權，並且在批量主機執行時，密碼需要一致

set passwd "passwd"

spawn ssh root@$ipaddr

expect

"password:"

}set timeout 3

#設定ps1的格式

send "export ps1=\\\"\[\\\u]\\\\$\\\"\r"

#期待接收到的返回

expect "*]#"

#建立乙個檔案驗證已經登入成功

send "touch /tmp/test.txt\r"

send "exit\r"

expect eof

exit若需要使用expect進行簡單自動化的主機，有事並不能完全**返回的結果，有一定的缺陷，但在自動化管理中還是很有用的，當然也需要考慮到不同的主機環境可能不一致的情況，這時需要做乙個統一。或者使用if，while等條件語句進行進一步的優化