這八個建議，來源于鍵者幾年來編寫 shell 腳本的一些經驗和教訓。事實上開始寫的時候還不止這幾條，后來思索再三，去掉幾條無關痛癢的，最后剩下八條。毫不夸張地說，每條都是精挑細選的，雖然有幾點算是老生常談了。

1. 指定bash

shell 腳本的第一行，#!之后應該是什么？如果拿這個問題去問別人，不同的人的回答可能各不相同。

我見過/usr/bin/env bash，也見過/bin/bash，還有/usr/bin/bash，還有/bin/sh，還有/usr/bin/env sh。這算是編程界的“'茴'字四種寫法”了。

在多數情況下，以上五種寫法都是等價的。但是，寫過程序的人都知道：“少數情況”里往往隱藏著意想不到的坑。

如果系統的默認 shell 不是 bash 怎么辦？比如某 Linux 發行版的某個版本，默認的 sh 就不是 bash。

如果系統的 bash 不是在 /usr/bin/bash 怎么辦？

我推薦使用 /usr/bin/env bash 和 /bin/bash。前者通過env添加一個中間層，讓env在$PATH中搜索bash；后者則是官方背書的，約定俗成的 bash 位置，/usr/bin/bash不過是指向它的一個符號鏈接。

2. set -e 和 set -x

OK，經過一番討論，現在第一行定下來了。接下來該開始寫第二行了吧？

且慢！在你開始構思并寫下具體的代碼邏輯之前，先插入一行set -e和一行set -x。

set -x會在執行每一行 shell 腳本時，把執行的內容輸出來。它可以讓你看到當前執行的情況，里面涉及的變量也會被替換成實際的值。

set -e會在執行出錯時結束程序，就像其他語言中的“拋出異常”一樣。（準確說，不是所有出錯的時候都會結束程序，見下面的注）

注：set -e結束程序的條件比較復雜，在man bash里面，足足用了一段話描述各種情景。大多數執行都會在出錯時退出，除非 shell 命令位于以下情況：

一個 pipeline 的非結尾部分，比如 error | ok

一個組合語句的非結尾部分，比如 ok && error || other

一連串語句的非結尾部分，比如 error; ok

位于判斷語句內，包括test、if、while等等。
這兩個組合在一起用，可以在 debug 的時候替你節省許多時間。出于防御性編程的考慮，有必要在寫第一行具體的代碼之前就插入它們。捫心自問，寫代碼的時候能夠一次寫對的次數有多少？大多數代 碼，在提交之前，通常都經歷過反復調試修改的過程。與其在焦頭爛額之際才引入這兩個配置，不如一開始就給 debug 留下余地。在代碼終于可以提交之后，再考慮是否保留它們也不遲。

3. 帶上shellcheck

好了，現在我已經有了三行（樣板）代碼，具體的業務邏輯一行都沒寫呢。是不是該開始寫了？