1 回答

TA貢獻1712條經驗 獲得超3個贊
這里實際上有三種選擇:在進程中做某事(如paramiko
)、ssh
直接運行(使用subprocess
)和ssh
使用shell運行(也使用subprocess
)。作為一般規則,避免以編程方式運行 shell(而不是根據交互式用戶請求)。
原因是它是一個以人為本的界面(因此很容易將單詞與空格、快捷鍵$HOME
和通配符分開)作為 API 的功能大大不足。例如,考慮一下您的代碼如何檢測到ssh
丟失的情況:這種情況不會出現paramiko
(只要它已安裝),很明顯subprocess
,并且只是來自 shell 的(模棱兩可的)退出代碼和 stderr 消息。還要考慮如何提供要運行的命令:它必須是適合 shell 的命令(由于 SSH 協議的限制),但如果ssh
使用shell 調用,則必須對其進行編碼(有時稱為“雙重轉義”)以使本地 shell 的解釋成為遠程 shell 所需的多字命令。
到目前為止,paramiko
幾乎subprocess
是等價的。作為一個更困難的情況,考慮密鑰驗證失敗將如何表現:paramiko
將失敗描述為data,而其他人將嘗試與用戶交互(可能存在也可能不存在)。 paramiko
還支持在一個經過身份驗證的連接上打開多個通道;ssh
這樣做也是如此,但只能通過ControlMaster
涉及 Unix 套接字文件的復雜配置(在某些部署中可能沒有任何好地方存在)。說到配置,如果在設計時沒有考慮到這種自動化用例,您可能需要通過-F
以避免用戶的復雜性。.ssh/config
總之,庫是為像您這樣的用例而設計的,因此它們比從面向人類的命令組裝您自己的界面(盡管這種手動組合非常有用)更好地工作也就不足為奇了,特別是對于邊緣情況可能?。?。如果安裝一個非標準的依賴喜歡paramiko
是一種負擔,至少直接使用subprocess
;去掉第二個殼已經是很大的進步了。
添加回答
舉報