#!/bin/bash set -e
在文件開頭加上set -e,這句語句告訴bash如果任何語句的執行結果不是true則應該退出。
這樣的好處是防止錯誤像滾雪球般變大導致一個致命的錯誤，而這些錯誤本應該在之前就被處理掉。如果要增加可讀性，可以使用set -o errexit，它的作用與set -e相同。
使用-e幫助你檢查錯誤。如果你忘記檢查（執行語句的結果），bash會幫你執行。
也就是說，在"set -e"之后出現的代碼，一旦出現了返回值非零，整個腳本就會立即退出。有的人喜歡使用這個參數，是出於保證代碼安全性的考慮。但有的時候，這種美好的初衷，也會導致嚴重的問題。
網上案例：
腳本a.sh開頭使用了"set -e"，且能正常運行。在幾個月或更久以后，因需求升級，在腳本中增加了3行hadoop操作：
#!/bin/bash
set -e
...
/home/work/.../hadoop dfs -rmr /app/.../dir
/home/work/.../hadoop dfs -mkdir /app/.../dir
/home/work/.../hadoop dfs -put file_1 /app/.../dir/
...
這幾行hadoop命令邏輯很簡單：在hdfs上清除並新建一個目錄，並將一份本地文件推送至這個目錄，供后續使用。將這幾行單拎出來，在命令行下執行，除了提示待刪除的目錄不存在，並沒有什么問題，文件還是會被推送到指定的地方。
但第一次執行這個腳本的時候，卻失敗退出了，且導致調用該腳本的程序整體退出，造成了嚴重的后果。原因是hdfs上還沒有這個目錄，rmr這一行會返回255，這個值被腳本前方的"set -e"捕捉到，直接導致了腳本退出。
新增的代碼本身並沒有問題，先刪除再新建目錄，反而是保證數據安全的比較規范的操作，刪除命令本身的容錯性，可以保證后續命令正常執行。事實是這個腳本有好幾百行，且邏輯比較復雜，在增加這幾行代碼的時候，開發人員已經不記得這個腳本里還有個"set -e"埋伏着了。
可見設置"set -e"，在腳本開發過程中可能很有幫助，而在開發完成后，特別是對於后期可能有升級的腳本，則可能是埋下了安全隱患。