我有一些RSYNC的呼叫，就像下面的例子一樣。由于各種原因，RSYNC的錯誤代碼也是需要的，并在陳述句后使用 上面的陳述句需要改變，以記錄RSYNC的輸出。根據我的理解，這很像SUDO等其他情況，在同一層次上增加shell重定向是行不通的。而不是RSYNC，shell重定向將覆寫NICE的輸出，也許取決于NICE內部的實際作業方式。無論如何，用它自己的特定重定向來啟動一個新的應總是安全的，就像下面的例子：$?檢索。AFAIK，即使在這個例子中執行了兩條命令，錯誤代碼也應該是RSYNC而不是NICE的。不過，我不知道NICE是否在設計中轉發了RSYNC的代碼，還是用RSYNC替換了自己，所以只有那個代碼被生成。無論如何，這并不重要，收到的代碼會正確地映射到RSYNC的行為方式。
/[...]/nice [...] /[...]/rsync [...]
/[...]/nice [...] bash -c "/[...]/rsync [...] > [...] 2> & 1"
這里是重點。在該陳述句之后的$?現在檢索的是哪個錯誤代碼？
BASH是回傳最后執行的命令的錯誤代碼，還是總是回傳0，因為它自己的執行已經成功？如果它轉發RSYNC的錯誤代碼，一切都會很好，就像過去不使用中間的BASH。然而，可能有必要在出現錯誤時額外觸發BASH退出，可能會這樣轉發最后的錯誤代碼：
/[...]/nice [...] bash -c "set -o errexit ; /[...]/rsync [...] > [...] 2> & 1" /span>
我在shell上用rsync --version與rsync --version_測驗了第二個和第三個例子，后者導致了RSYNC的錯誤資訊。在這兩種情況下，BASH似乎都正確地回傳了RSYNC本身的錯誤代碼。雖然，我找不到太多關于這種行為的檔案，例如在使用-c執行多個命令的情況下會發生什么。
那么，如何正確檢查使用bash -c '[...]'/code>執行的命令的錯誤代碼？例如，set -o errexit是否有必要，甚至可能會造成傷害？
謝謝！
uj5u.com熱心網友回復：
Bash的退出代碼是它最后執行的命令的退出代碼。
set -e / set -o errexit并沒有改變這一點。 通過實驗很容易建立：
bash$ bash -c 'exit 17'; echo $?
17
bash$ bash -c 'set -e; bash -c "exit 17"; echo still here'/span>; echo $?
17
bash$ bash -c 'set -e; nice -1 bash -c "exit 17"; echo still here'; echo $?
17
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/307693.html
標籤：
上一篇：如何在pandas中過濾某些條件并同時應用一個函式？
下一篇：默認Vim總是在新標簽中打開幫助