每個人或多或少總會碰到要使用並且自己完成編寫一個最基礎的Bash指令碼的情況。真實情況是，沒有人會說“哇哦，我喜歡寫這些指令碼”。所以這也是為什麼很少有人在寫的時候專注在這些指令碼上。

我本身也不是一個Bash指令碼專家，但是我會在本文中跟你展示一個最基礎最簡單的安全指令碼模板，會讓你寫的Bash指令碼更加安全實用，你掌握了之後肯定會受益匪淺。

為什麼要寫Bash指令碼

其實關於Bash指令碼最好的解釋如下：

The opposite of "it's like riding a bike" is "it's like programming in bash".

A phrase which means that no matter how many times you do something, you will have to re-learn it every single time.

— Jake Wharton (@JakeWharton)

December 2, 2020

意思就是，跟騎腳踏車相反，無論做了多少次，每次都感覺像重新學一樣。

Bash就像繼承了shell的衣缽一樣，在每臺linux上都可以看到他的身影，這可是大多數後端程式執行的環境，因此當你需要編寫伺服器的應用程式啟動、CI/CD步驟或整合測試用的指令碼，Bash就在那裡等著你。

將幾個命令粘在一起，將輸出從一個傳遞到另一個，然後只啟動一些可執行檔案，Bash是眾多方案中最簡單的一個。雖然用其他語言編寫更大、更復雜的指令碼更有效果，但你不能指望Python、Ruby、fish或其他任何你認為最好的程式，可以在任何地方編譯使用。所以在將其新增到某個prod server、Docker image或CI環境之前，往往會讓人三思而後行。

當然啦，Bash還遠遠不夠完美兩個字。他的語法對初學者就像一個噩夢。錯誤處理也很困難。到處都是我們必須處理掉的陷阱。

Bash script template（Bash指令碼模板）

廢話不多說，獻上我的模板

#!/usr/bin/env bashset -Eeuo pipefailtrap cleanup SIGINT SIGTERM ERR EXITscript_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P)usage() {  cat <<EOFUsage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...]Script description here.Available options:-h, --help      Print this help and exit-v, --verbose   Print script debug info-f, --flag      Some flag description-p, --param     Some param descriptionEOF  exit}cleanup() {  trap - SIGINT SIGTERM ERR EXIT  # script cleanup here}setup_colors() {  if [[ -t 2 ]] && [[ -z "${NO_COLOR-}" ]] && [[ "${TERM-}" != "dumb" ]]; then    NOFORMAT='\033[0m' RED='\033[0;31m' GREEN='\033[0;32m' ORANGE='\033[0;33m' BLUE='\033[0;34m' PURPLE='\033[0;35m' CYAN='\033[0;36m' YELLOW='\033[1;33m'  else    NOFORMAT='' RED='' GREEN='' ORANGE='' BLUE='' PURPLE='' CYAN='' YELLOW=''  fi}msg() {  echo >&2 -e "${1-}"}die() {  local msg=$1  local code=${2-1} # default exit status 1  msg "$msg"  exit "$code"}parse_params() {  # default values of variables set from params  flag=0  param=''  while :; do    case "${1-}" in    -h | --help) usage ;;    -v | --verbose) set -x ;;    --no-color) NO_COLOR=1 ;;    -f | --flag) flag=1 ;; # example flag    -p | --param) # example named parameter      param="${2-}"      shift      ;;    -?*) die "Unknown option: $1" ;;    *) break ;;    esac    shift  done  args=("$@")  # check required params and arguments  [[ -z "${param-}" ]] && die "Missing required parameter: param"  [[ ${#args[@]} -eq 0 ]] && die "Missing script arguments"  return 0}parse_params "$@"setup_colors# script logic heremsg "${RED}Read parameters:${NOFORMAT}"msg "- flag: ${flag}"msg "- param: ${param}"msg "- arguments: ${args[*]-}"

Choose Bash

#!/usr/bin/env bash

指令碼為了獲得最佳相容性，它引用/usr/bin/env，而不是直接引用/bin/bash。

Fail fast

set -Eeuo pipefail

set命令可以更改指令碼執行選項。例如，通常Bash不關心某個命令是否失敗，返回非零退出狀態程式碼。它只是快速地跳到下一個。現在考慮一下這個小指令碼：

#!/usr/bin/env bashcp important_file ./backups/rm important_file

如果備份目錄不存在，會發生什麼情況？確切地說，你將在控制檯中收到一條錯誤訊息，但是在你能夠做出反應之前，該檔案已經被第二個命令刪除。

Get the location

script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P)

這行程式碼盡其所能定義指令碼的位置目錄，然後我們對其進行cd配置。為什麼？

通常，我們的指令碼在相對於指令碼位置的路徑上執行，複製檔案並執行命令，假設指令碼目錄也是一個工作目錄。是的，只要我們從它的目錄執行指令碼。

但是，假設我們的CI配置執行指令碼如下所示呢：

/opt/ci/project/script.sh

那麼我們的指令碼不是在專案目錄中操作的，而是在CI工具的一些完全不同的工作目錄中操作的。我們可以透過在執行指令碼之前轉到目錄來修復它：

cd /opt/ci/project && ./script.sh

但從指令碼的角度解決這個問題要好得多。因此，如果指令碼從同一目錄中讀取某個檔案或執行另一個程式，請按如下方式呼叫：

cat "$script_dir/my_file"

同時，指令碼不會更改工作目錄的位置。如果指令碼是從其他目錄執行的，並且使用者提供了指向某個檔案的相對路徑，我們仍然可以讀取它。

Try to clean up

trap cleanup SIGINT SIGTERM ERR EXITcleanup() {  trap - SIGINT SIGTERM ERR EXIT  # script cleanup here}

在指令碼結束時，將執行cleanup（）函式。你可以在這裡嘗試刪除指令碼建立的所有臨時檔案。

請記住，cleanup（）不僅可以在最後呼叫，在任何時候都可以。

Display helpful help

usage() {  cat <<EOFUsage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...]Script description here....EOF  exit}

儘量讓usage（）函式相對靠近指令碼的頂部，有兩種作用：

要為不知道所有選項並且不想檢視整個指令碼來發現這些選項的人顯示幫助。當有人修改指令碼時，儲存一個最小的文件（因為兩週後，你甚至不記得當初是怎麼寫的）。

我不主張在這裡記錄每個函式。但是一個簡短、漂亮的指令碼使用這些訊息是必需的。

Print nice messages

setup_colors() {  if [[ -t 2 ]] && [[ -z "${NO_COLOR-}" ]] && [[ "${TERM-}" != "dumb" ]]; then    NOFORMAT='\033[0m' RED='\033[0;31m' GREEN='\033[0;32m' ORANGE='\033[0;33m' BLUE='\033[0;34m' PURPLE='\033[0;35m' CYAN='\033[0;36m' YELLOW='\033[1;33m'  else    NOFORMAT='' RED='' GREEN='' ORANGE='' BLUE='' PURPLE='' CYAN='' YELLOW=''  fi}msg() {  echo >&2 -e "${1-}"}

首先，如果你還不想在文字中使用顏色，那麼先刪除setup_colors（）函式。我保留它是因為我知道如果我不必每次都用谷歌編碼的話，我會更頻繁地使用顏色。

其次，這些顏色只用於msg（）函式，而不是echo命令。

msg（）函式用於列印不是指令碼輸出的所有內容。這包括所有日誌和訊息，而不僅僅是錯誤。引用 12 Factor CLI Apps的文章說法：

In short: stdout is for output, stderr is for messaging.

— Jeff Dickey, who knows a little about building CLI apps

stdout用於輸出，stderr用於訊息傳遞。

這就是為什麼在大多數情況下你不應該為stdout使用顏色。

用msg（）列印的訊息被髮送到stderr流並支援特殊的序列，比如顏色。如果stderr輸出不是互動式終端，或者傳遞了一個標準引數，那麼顏色將被禁用。用法如下：

msg "This is a ${RED}very important${NOFORMAT} message, but not a script output value!"

要檢查stderr是不是互動式終端時的行為，請在指令碼中新增類似於上面的一行。然後執行它，將stderr重定向到stdout並透過管道將其傳送到cat。管道操作使輸出不再直接傳送到終端，而是傳送到下一個命令，因此顏色會被禁用。

$ ./test.sh 2>&1 | catThis is a very important message, but not a script output value!

Parse any parameters

parse_params() {  # default values of variables set from params  flag=0  param=''  while :; do    case "${1-}" in    -h | --help) usage ;;    -v | --verbose) set -x ;;    --no-color) NO_COLOR=1 ;;    -f | --flag) flag=1 ;; # example flag    -p | --param) # example named parameter      param="${2-}"      shift      ;;    -?*) die "Unknown option: $1" ;;    *) break ;;    esac    shift  done  args=("$@")  # check required params and arguments  [[ -z "${param-}" ]] && die "Missing required parameter: param"  [[ ${#args[@]} -eq 0 ]] && die "Missing script arguments"  return 0}

如果在指令碼中引數化有意義的話，我就通常就會去做，即使整個指令碼只在一個地方使用。它使複製和重用它變得更容易，而這通常是早晚發生的。而且，即使某些東西需要硬編碼，通常在比Bash指令碼更高的級別上有更好的位置。

CLI引數有三種主要型別：標誌、命名引數和位置引數。parse_params（）函式支援所有這些引數。

這裡沒有處理的唯一一個公共引數模式是連線多個單字母標誌。為了能夠傳遞兩個標誌作為-ab，而不是-a-b，需要一些額外的程式碼。

while迴圈是一種手動解析引數的方法。在其他語言中，您應該使用一個內建的解析器或可用的庫，但是，好吧，這是Bash。

模板中有一個示例標誌（-f）和命名引數（-p）。只需更改或複製它們以新增其他引數。之後不要忘記更新usage（）。

這裡最重要的一點是，當您使用第一個google結果進行Bash引數解析時，通常會丟失一個未知選項的錯誤。指令碼收到未知選項的事實意味著使用者希望它執行指令碼無法完成的操作。所以使用者的期望和指令碼行為可能會有很大的不同。最好是在壞事發生之前完全阻止處決。

在Bash中解析引數有兩種選擇。是一個接一個的。有人贊成和反對使用它們。我發現這些工具不是最好的，因為預設情況下，macOS上的getopt行為完全不同，getopts不支援長引數（比如--help）。

Using the template

複製貼上它，就像你在網上找到的大多數程式碼一樣。

複製後，只需更改4件事：

包含指令碼說明的usage（）文字cleanup（）內容parse_params（）中的引數–保留--help和--no color，但替換示例：-f和-p實際的指令碼邏輯Portability

我在MacOS上測試了這個模板（使用預設的bash3.2）和幾個Docker映像：Debian、Ubuntu、CentOS、amazonlinux、Fedora。它的確起作用了。

顯然，它不能在缺少Bash的環境中工作，比如alpinellinux。

Further reading

在用Bash或其他更好的語言建立CLI指令碼時，有一些通用規則。這些資源將指導您如何使小型指令碼和大型CLI應用程式可靠，參考如下：

Command Line Interface Guidelines（https://clig.dev/）12 Factor CLI Apps（https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46）Command line arguments anatomy explained with examples（https://betterdev.blog/command-line-arguments-anatomy-explained/）Closing notes

我不會是第一個也不是最後一個建立Bash指令碼模板的人。這個專案是一個很好的選擇，雖然對我的日常需求來說有點太大了。畢竟，我儘量使Bash指令碼儘可能小（而且很少使用）。

編寫Bash指令碼時，請使用支援ShellCheck linter的IDE，如JetBrains IDEs。它會阻止你做一堆適得其反的事情。