怎么編寫(xiě)一個(gè)Bash腳本

怎么編寫(xiě)一個(gè)Bash腳本？很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

為什么要寫(xiě)B(tài)ash腳本

其實(shí)關(guān)于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

意思就是，跟騎自行車相反，無(wú)論做了多少次，每次都感覺(jué)像重新學(xué)一樣。

但是Bash腳本語(yǔ)言和其他一些廣受歡迎的語(yǔ)言，例如JavaScript一樣，他們不會(huì)輕易突然消失，雖然Bash腳本語(yǔ)言不太可能成為業(yè)界的主流語(yǔ)言，但實(shí)際他就在我們周圍，無(wú)處不在。

Bash就像繼承了shell的衣缽一樣，在每臺(tái)linux上都可以看到他的身影，這可是大多數(shù)后端程序運(yùn)行的環(huán)境，因此當(dāng)你需要編寫(xiě)服務(wù)器的應(yīng)用程序啟動(dòng)、CI/CD步驟或集成測(cè)試用的腳本，Bash就在那里等著你。

將幾個(gè)命令粘在一起，將輸出從一個(gè)傳遞到另一個(gè)，然后只啟動(dòng)一些可執(zhí)行文件，Bash是眾多方案中最簡(jiǎn)單的一個(gè)。雖然用其他語(yǔ)言編寫(xiě)更大、更復(fù)雜的腳本更有效果，但你不能指望Python、Ruby、fish或其他任何你認(rèn)為最好的程序，可以在任何地方編譯使用。所以在將其添加到某個(gè)prod server、Docker image或CI環(huán)境之前，往往會(huì)讓人三思而后行。

當(dāng)然啦，Bash還遠(yuǎn)遠(yuǎn)不夠完美兩個(gè)字。他的語(yǔ)法對(duì)初學(xué)者就像一個(gè)噩夢(mèng)。錯(cuò)誤處理也很困難。到處都是我們必須處理掉的陷阱。

Bash script template（Bash腳本模板）

廢話不多說(shuō)，獻(xiàn)上我的模板

#!/usr/bin/env bash

set -Eeuo pipefail
trap cleanup SIGINT SIGTERM ERR EXIT

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

usage() {
 cat <<EOF
Usage: $(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 description
EOF
 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 here

msg "${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命令可以更改腳本執(zhí)行選項(xiàng)。例如，通常Bash不關(guān)心某個(gè)命令是否失敗，返回非零退出狀態(tài)代碼。它只是快速地跳到下一個(gè)?，F(xiàn)在考慮一下這個(gè)小腳本：

#!/usr/bin/env bash
cp important_file ./backups/
rm important_file

如果備份目錄不存在，會(huì)發(fā)生什么情況？確切地說(shuō)，你將在控制臺(tái)中收到一條錯(cuò)誤消息，但是在你能夠做出反應(yīng)之前，該文件已經(jīng)被第二個(gè)命令刪除。

Get the location

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

這行代碼盡其所能定義腳本的位置目錄，然后我們對(duì)其進(jìn)行cd配置。為什么？

通常，我們的腳本在相對(duì)于腳本位置的路徑上運(yùn)行，復(fù)制文件并執(zhí)行命令，假設(shè)腳本目錄也是一個(gè)工作目錄。是的，只要我們從它的目錄執(zhí)行腳本。

但是，假設(shè)我們的CI配置執(zhí)行腳本如下所示呢：

/opt/ci/project/script.sh

那么我們的腳本不是在項(xiàng)目目錄中操作的，而是在CI工具的一些完全不同的工作目錄中操作的。我們可以通過(guò)在執(zhí)行腳本之前轉(zhuǎn)到目錄來(lái)修復(fù)它：

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

但從腳本的角度解決這個(gè)問(wèn)題要好得多。因此，如果腳本從同一目錄中讀取某個(gè)文件或執(zhí)行另一個(gè)程序，請(qǐng)按如下方式調(diào)用：

cat "$script_dir/my_file"

同時(shí)，腳本不會(huì)更改工作目錄的位置。如果腳本是從其他目錄執(zhí)行的，并且用戶提供了指向某個(gè)文件的相對(duì)路徑，我們?nèi)匀豢梢宰x取它。

Try to clean up

trap cleanup SIGINT SIGTERM ERR EXIT

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

在腳本結(jié)束時(shí)，將執(zhí)行cleanup（）函數(shù)。你可以在這里嘗試刪除腳本創(chuàng)建的所有臨時(shí)文件。

請(qǐng)記住，cleanup（）不僅可以在最后調(diào)用，在任何時(shí)候都可以。

Display helpful help

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

Script description here.

...
EOF
 exit
}

盡量讓usage（）函數(shù)相對(duì)靠近腳本的頂部，有兩種作用：

• 要為不知道所有選項(xiàng)并且不想查看整個(gè)腳本來(lái)發(fā)現(xiàn)這些選項(xiàng)的人顯示幫助。

• 當(dāng)有人修改腳本時(shí)，保存一個(gè)最小的文檔（因?yàn)閮芍芎?，你甚至不記得?dāng)初是怎么寫(xiě)的）。

我不主張?jiān)谶@里記錄每個(gè)函數(shù)。但是一個(gè)簡(jiǎn)短、漂亮的腳本使用這些消息是必需的。

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（）函數(shù)。我保留它是因?yàn)槲抑廊绻也槐孛看味加霉雀杈幋a的話，我會(huì)更頻繁地使用顏色。

其次，這些顏色只用于msg（）函數(shù)，而不是echo命令。

msg（）函數(shù)用于打印不是腳本輸出的所有內(nèi)容。這包括所有日志和消息，而不僅僅是錯(cuò)誤。引用
12 Factor CLI Apps的文章說(shuō)法：

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

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

stdout用于輸出，stderr用于消息傳遞。

這就是為什么在大多數(shù)情況下你不應(yīng)該為stdout使用顏色。

用msg（）打印的消息被發(fā)送到stderr流并支持特殊的序列，比如顏色。如果stderr輸出不是交互式終端，或者傳遞了一個(gè)標(biāo)準(zhǔn)參數(shù)，那么顏色將被禁用。
用法如下：

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

要檢查stderr是不是交互式終端時(shí)的行為，請(qǐng)?jiān)谀_本中添加類似于上面的一行。然后執(zhí)行它，將stderr重定向到stdout并通過(guò)管道將其發(fā)送到cat。管道操作使輸出不再直接發(fā)送到終端，而是發(fā)送到下一個(gè)命令，因此顏色會(huì)被禁用。

$ ./test.sh 2>&1 | cat
This 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
}

如果在腳本中參數(shù)化有意義的話，我就通常就會(huì)去做，即使整個(gè)腳本只在一個(gè)地方使用。它使復(fù)制和重用它變得更容易，而這通常是早晚發(fā)生的。而且，即使某些東西需要硬編碼，通常在比Bash腳本更高的級(jí)別上有更好的位置。

CLI參數(shù)有三種主要類型：標(biāo)志、命名參數(shù)和位置參數(shù)。parse_params（）函數(shù)支持所有這些參數(shù)。

這里沒(méi)有處理的唯一一個(gè)公共參數(shù)模式是連接多個(gè)單字母標(biāo)志。為了能夠傳遞兩個(gè)標(biāo)志作為-ab，而不是-a-b，需要一些額外的代碼。

while循環(huán)是一種手動(dòng)解析參數(shù)的方法。在其他語(yǔ)言中，您應(yīng)該使用一個(gè)內(nèi)置的解析器或可用的庫(kù)，但是，好吧，這是Bash。

模板中有一個(gè)示例標(biāo)志（-f）和命名參數(shù)（-p）。只需更改或復(fù)制它們以添加其他參數(shù)。之后不要忘記更新usage（）。

這里最重要的一點(diǎn)是，當(dāng)您使用第一個(gè)google結(jié)果進(jìn)行Bash參數(shù)解析時(shí)，通常會(huì)丟失一個(gè)未知選項(xiàng)的錯(cuò)誤。腳本收到未知選項(xiàng)的事實(shí)意味著用戶希望它執(zhí)行腳本無(wú)法完成的操作。所以用戶的期望和腳本行為可能會(huì)有很大的不同。最好是在壞事發(fā)生之前完全阻止處決。

在Bash中解析參數(shù)有兩種選擇。是一個(gè)接一個(gè)的。有人贊成和反對(duì)使用它們。我發(fā)現(xiàn)這些工具不是最好的，因?yàn)槟J(rèn)情況下，macOS上的getopt行為完全不同，getopts不支持長(zhǎng)參數(shù)（比如--help）。

Using the template

復(fù)制粘貼它，就像你在網(wǎng)上找到的大多數(shù)代碼一樣。

復(fù)制后，只需更改4件事：

• 包含腳本說(shuō)明的usage（）文本

• cleanup（）內(nèi)容

• parse_params（）中的參數(shù)–保留--help和--no color，但替換示例：-f和-p

• 實(shí)際的腳本邏輯
  

Portability

我在MacOS上測(cè)試了這個(gè)模板（使用默認(rèn)的bash4.2）和幾個(gè)Docker映像：Debian、Ubuntu、CentOS、amazonlinux、Fedora。它的確起作用了。

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

Further reading

在用Bash或其他更好的語(yǔ)言創(chuàng)建CLI腳本時(shí)，有一些通用規(guī)則。這些資源將指導(dǎo)您如何使小型腳本和大型CLI應(yīng)用程序可靠，參考如下：

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

我不會(huì)是第一個(gè)也不是最后一個(gè)創(chuàng)建Bash腳本模板的人。這個(gè)項(xiàng)目是一個(gè)很好的選擇，雖然對(duì)我的日常需求來(lái)說(shuō)有點(diǎn)太大了。畢竟，我盡量使Bash腳本盡可能?。ǘ液苌偈褂茫?。

編寫(xiě)B(tài)ash腳本時(shí)，請(qǐng)使用支持ShellCheck linter的IDE，如JetBrains IDEs。它會(huì)阻止你做一堆適得其反的事情。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。