：從踩坑到高效自動化運維)
從事Linux運維和開發(fā)這些年shell腳本是我每天都會碰的東西。做日志切割、批量改文件、寫定時任務、數(shù)據同步、環(huán)境初始化一件件看起來雞毛蒜皮的小事最后都是靠腳本把人力省下來的。這是我自己筆記的第十六篇前面寫過系統(tǒng)啟動、權限、磁盤、網絡這些基礎內容這篇專門聊聊shell腳本把我這些年踩過的坑和覺得有價值的寫法一次性梳理出來希望能幫正在學腳本的讀者少走幾步彎路。這篇內容不打算從什么是變量這種教科書概念開始而是直接以實戰(zhàn)視角切入什么時候該寫腳本、腳本骨架怎么搭、核心語法怎么用才不出錯、完整案例怎么落地、出了問題怎么排查。適合已經會敲基本命令、想把零散命令變成可復用工具的讀者如果你是完全零基礎可以先拿著基本命令練幾遍再來看這篇效果會更好。1. 什么時候真正需要動手寫腳本1.1 腳本最擅長解決的幾類問題先說實話不是所有事情都值得寫成腳本。我自己判斷的標準很簡單這件事是不是要重復做兩次以上是不是需要多個命令配合才能完成如果答案都是肯定的那基本就該寫了。最常見的場景我列一下批量操作類幾十臺機器上收集信息、幾百個文件統(tǒng)一改名、批量壓縮解壓。手工敲一條條命令又累又容易漏腳本跑一遍還能留下輸出日志。定時任務類日志清理、數(shù)據備份、臨時文件歸檔、健康檢查告警。cron加腳本是絕配腳本負責邏輯cron負責定時觸發(fā)。部署與初始化類新機器裝環(huán)境、初始化配置、重啟服務。這類操作步驟多且有固定順序寫成腳本后可以反復執(zhí)行也方便在出問題時快速重來。格式轉換與數(shù)據處理把CSV轉成另一種格式、從日志里面提取關鍵字段、批量替換文件內容。配合awk、sed、grep這些工具一個瘦腳本就能解決很多所謂大數(shù)據需求的土辦法方案。我遇到最多的是日志相關。比如業(yè)務系統(tǒng)每天產生的日志文件按照日期命名超過30天的需要刪除磁盤空間到80%需要告警。這種需求用手工做根本不現(xiàn)實定時跑一個腳本才是正解。后面我會把這個完整腳本展開講。即使是臨時性任務只要我開始覺得這串命令要重復手敲兩遍也會順手寫成腳本。寫的時候可能只花三分鐘但后面再遇到類似需求把腳本翻出來改兩行就能用。腳本庫就是這么一點一點攢出來的。1.2 別把腳本當萬能鑰匙shell腳本也不是沒有短板。遇到下面這幾類情況我建議換個工具而不是硬撐。一是性能敏感的大數(shù)據處理。比如幾GB的日志要算統(tǒng)計指標shell里一層層循環(huán)會慢到讓人懷疑人生這時候用Python、Go甚至直接上SQL都更合適。shell適合做膠水層面的組織和協(xié)調不適合做重計算。二是邏輯特別復雜的流程。判斷分支多了、狀態(tài)多了、需要復雜數(shù)據結構的場景shell寫起來會很痛苦調試也費勁。腳本里出現(xiàn)幾十行嵌套if基本就是該重構或者換更合適語言重寫的信號。三是跨平臺要求高的場景。雖然bash在各種Linux發(fā)行版上都通用但有些命令在不同發(fā)行版上行為略有差別macOS自帶的是舊版bashWindows上更是另一套。如果腳本要在完全不同的環(huán)境里跑要么用Python這類跨平臺解釋器要么在腳本里做足兼容判斷。我的經驗是能用標準命令組合解決的就用腳本感覺腳本寫起來已經很別扭了果斷換語言。工具選對了后面維護的成本才會低。1.3 動手前先想清楚三個問題寫一個腳本之前先花兩分鐘想三件事輸入是什么、輸出是什么、中間有哪些約束。輸入可能是配置文件、命令行參數(shù)或環(huán)境變量輸出可能是處理后的文件、日志記錄或一個退出碼約束包括運行權限、運行時間窗口、磁盤空間上限等。想清楚這三件事腳本的結構基本就出來了。然后遵循一個原則一個腳本只干一件事。把功能拆成函數(shù)每個函數(shù)只做它負責的那部分。這樣做的好處是定位問題快、復用方便也方便以后把腳本拆成更細的模塊。我早期寫腳本總是一個腳本解決所有問題結果腳本越來越長改一個邏輯就動到全局線上出了故障排查得像考古。吃過虧以后才養(yǎng)成先拆功能、再動手寫的習慣。2. 腳本骨架搭建與變量引用的關鍵細節(jié)2.1 shebang、執(zhí)行權限和首行配置一個普通文本文件要讓系統(tǒng)當成腳本執(zhí)行需要兩個條件第一行以#!開頭指定解釋器并且文件要有執(zhí)行權限。第一行寫#!/bin/bash還是#!/usr/bin/env bash兩者都能用但意義不同。直接寫#!/bin/bash是明確指定解釋器路徑性能稍好兼容性也更容易預料。寫#!/usr/bin/env bash是先找到bash所在路徑再執(zhí)行在bash不在標準位置的系統(tǒng)上更靈活但env本身如果找不到也會帶來問題。我自己在服務器上習慣直接寫#!/bin/bash因為標準發(fā)行版上bash基本都在這個位置少一層解析也更穩(wěn)。執(zhí)行權限用chmod x script.sh加上。這一步很多人忽略導致明明腳本沒問題卻提示Permission denied。另外如果在當前目錄運行腳本要寫成./script.sh而不是script.sh因為當前目錄通常不在PATH環(huán)境變量里。這個踩坑率極高尤其是剛從Windows轉到Linux環(huán)境的讀者。首行配置我還建議加兩樣東西一是文件頭的注釋寫明腳本用途、創(chuàng)建時間和維護人二是set選項。雖然set選項后面詳細講但我現(xiàn)在寫任何腳本開頭幾乎固定是#!/bin/bash # 功能xxxx # 創(chuàng)建2024-xx-xx set -euo pipefailset -euo pipefail這一行帶來的變化我后面詳細說先記住它能讓腳本在出錯時立刻暴露問題而不是帶病往下跑。2.2 變量取值與引號使用的門道變量賦值在shell里看似簡單坑全藏在細節(jié)中。賦值語句等號兩邊不能有空格寫成name 張三會變成執(zhí)行命令name直接報command not found。這個錯誤我見新人踩過無數(shù)次。取變量值用$name但更嚴謹?shù)膶懛ㄊ?{name}。兩者差別在變量名后面緊跟其他字符時體現(xiàn)出來echo $name_file會把name_file當成一個變量名而echo ${name}_file才是取name變量的值再加下劃線和file。凡是變量名邊界不清晰的場景一律用${}包裹這是一個讓腳本更清晰、更安全的好習慣。引號的使用是shell腳本最容易出問題的點。什么時候用雙引號什么時候不用規(guī)則其實很明確如果變量的值可能包含空格、通配符或其他特殊字符并且你希望它作為一個整體被處理就必須加雙引號。比如file_path/data/logs/app 2024.log if [ -f $file_path ]; then echo 文件存在 fi如果這里不加雙引號[ -f $file_path ]會被展開成[ -f /data/logs/app 2024.log ]test命令會因為參數(shù)個數(shù)不對直接報語法錯誤。雙引號的作用就是給整個值包一層不讓shell把里面的空格當成分隔符。還有一種情況是變量的值來源不可控比如讀取外部文件內容、命令輸出的結果這時候雙引號尤其重要。不加雙引號的話文件里如果有分號、感嘆號、星號之類的內容shell會做各種展開輕則結果不對重則執(zhí)行了本不該執(zhí)行的命令。我在這上面栽過跟頭一個讀取文件內容后再拼成命令發(fā)送的腳本文件里恰巧有分號結果一行原本正常的命令被拆成了兩條。從那以后凡是非我手寫的字符串默認一律加雙引號處理。命令替換是另一個常用特性$(command)會執(zhí)行命令并把輸出作為值。比如拿今天日期today$(date %F)。這里我建議優(yōu)先用$()而不是反引號因為反引號在處理嵌套時容易出錯$()可以嵌套可讀性也更好。注意命令替換的結果如果有換行符賦值給變量后會保留echo出來可能看到多行這在處理命令輸出時要心里有數(shù)。2.3 位置參數(shù)與入參檢查腳本接收外部輸入最常見的是位置參數(shù)$1、$2這種。比如./backup.sh /data/mysql /backup腳本里$1就是/data/mysql$2就是/backup。$#表示參數(shù)個數(shù)$表示所有參數(shù)并且每個參數(shù)獨立$也表示所有參數(shù)但視為一個整體。遍歷參數(shù)時應該用for arg in $而不是$這樣才能正確處理帶空格的參數(shù)值。腳本里的關鍵參數(shù)我習慣加一道檢查避免用戶忘了傳參導致腳本在后面某個莫名其妙的位置報錯。典型寫法if [ $# -lt 2 ]; then echo 用法: $0 源目錄 備份目錄 exit 1 fi這樣做的好處是錯誤信息明確而不是腳本跑了一大半才因為找不到文件而失敗。exit 1返回非零退出碼調用方可以據此判斷腳本執(zhí)行失敗。有時候參數(shù)是可選的需要默認值。shell的參數(shù)展開語法能直接處理${var:-默認值}表示var沒設置或為空時使用默認值。比如日志保留天數(shù)支持通過參數(shù)指定不指定就默認30天keep_days${1:-30}。這樣腳本既靈活又穩(wěn)妥。類似地${var:默認值}不但取默認值還給變量賦值${var:?提示信息}在變量為空時直接退出并輸出提示適合強制要求參數(shù)的場景。3. 條件判斷與循環(huán)的實戰(zhàn)細節(jié)3.1 條件測試寫法單中括號和雙中括號怎么選shell里做判斷本質上是運行一個test命令并根據它的退出碼決定分支。if [ ... ]中的方括號其實是test命令的另一種寫法所以方括號兩邊必須有空格[ $a $b ]寫成[ $a$b ]就會出錯因為shell把整個字符串當成了一個參數(shù)?，F(xiàn)代bash里更推薦用雙中括號[[ ... ]]。它是bash內置的關鍵詞支持更豐富的表達式比如和都可以用支持正則匹配也支持和||這種邏輯運算符。最關鍵的是在[[ ]]內部變量即使不加雙引號也不會被錯誤分詞對新手友好得多。我的建議是既然用的是bash直接統(tǒng)一用[[ ]]不要再拿單中括號去踩那些邊邊角角的坑。文件判斷操作符要記牢-f判斷是不是普通文件-d判斷是不是目錄-e判斷路徑是否存在-r、-w、-x判斷讀、寫、執(zhí)行權限-z和-n判斷字符串為空或非空。-nt和-ot可以比較文件的修改時間新舊在增量備份場景里很好用。數(shù)值比較用-eq、-ne、-gt、-lt而不是和因為在shell里是重定向符號寫錯會引發(fā)文件重定向非常隱蔽。邏輯判斷的寫法在[[ ]]里直接用和||if [[ -f $file -r $file ]]; then。在單中括號里要用-a和-o再加上各種轉義可讀性和安全性都差。所以堅持用[[ ]]能讓代碼干凈很多。3.2 for、while、until在什么場景下各司其職for循環(huán)適合遍歷已知列表遍歷一組文件、一組主機名、一組參數(shù)。最典型的是遍歷當前目錄下的所有txt文件for f in *.txt; do echo 處理文件: $f done注意*.txt在這里會先被shell展開成文件列表如果目錄里沒有匹配的文件展開結果會是字面的*.txt循環(huán)還是會執(zhí)行一次所以最好先判斷文件是否存在再進循環(huán)。遍歷時如果文件名有空格for f in *.txt這種寫法會出問題因為空格會被當成列表分隔。處理方法是用find配合while readfind . -name *.txt -print0 | while IFS read -r -d f; do echo 處理文件: $f done-print0把文件名以null分隔-d 讓read也按null分隔讀取。這個寫法看著繁瑣但它在處理帶空格、帶換行的文件名時百分之百可靠是處理任意文件名最穩(wěn)妥的方式。while循環(huán)適合條件驅動的場景讀文件直到文件結束、等待某個條件成立、消費某個隊列。最常見的while讀文件寫法while IFS read -r line; do echo $line done input.txtIFS防止行首行尾的空白被trim掉-r防止反斜杠被解釋 input.txt把文件作為循環(huán)的輸入。這種寫法比for i in $(cat input.txt)安全得多因為for配合$(cat)會把文件按空格、按換行全部分裂一遍文件內容稍微有點特殊字符就亂套了。until循環(huán)和while結構一樣只是條件為假時執(zhí)行。實際用得少但偶爾用來等待某個服務就緒還挺順手until nc -z 127.0.0.1 3306; do sleep 1; done一直等到數(shù)據庫端口能連通。循環(huán)里break可以提前跳出continue進入下一輪是兩個常用的控制指令不要忘記。3.3 管道、子shell與循環(huán)變量丟失問題這個問題我必須單獨提因為它坑過的絕對不止我一個人在管道后面接while循環(huán)循環(huán)內對變量的修改在循環(huán)結束后會丟失?？催@個經典例子count0 echo -e a\nb\nc | while read line; do count$((count 1)) done echo $count輸出是0而不是3。原因在于管道會讓while循環(huán)跑在一個子shell進程里子shell里的變量修改不會傳回父shell。我第一次遇到時百思不得其解查來查去才發(fā)現(xiàn)是shell的設計使然。解決思路有三種。第一種把輸入重定向而不是用管道while read line; do count$((count 1)) done (echo -e a\nb\nc)進程替換(command)產生的輸入通過重定向進入循環(huán)循環(huán)本身還在當前shell里運行變量修改就能保留。第二種是把結果寫到文件再讀出來。第三種是把處理邏輯封裝成函數(shù)后用輸出捕獲結果但本質上還是在子shell里靠的是函數(shù)輸出而非變量傳遞。這類子shell邊界問題在管道、find -exec、括號子shell里都會出現(xiàn)。遇到變量值詭異消失的現(xiàn)象第一反應就是檢查是不是跨越了子shell邊界。排查方法也很簡單在關鍵位置加echo輸出中間值看看循環(huán)內和循環(huán)外的值是否一致不一致基本就是邊界問題。4. 函數(shù)設計、退出碼與腳本健壯性4.1 用函數(shù)拆骨架local變量防污染腳本一長組織方式就成了大問題。我現(xiàn)在的習慣是腳本主體只保留流程調度真正的邏輯全部放進函數(shù)。函數(shù)定義用function name() {}或者直接name() {}都可以我傾向不帶function關鍵字和POSIX兼容性更好。函數(shù)里要特別注意變量的作用域。默認情況下函數(shù)里賦值的變量是全局的會污染腳本其他部分。所以凡是函數(shù)內部的臨時變量一律用local聲明local tmp_file/tmp/xxx。這能避免函數(shù)間因為同一個變量名互相影響排查問題時也清楚每個變量的歸屬。這個習慣和寫代碼時不讓函數(shù)偷偷改全局狀態(tài)是同一個道理。函數(shù)內用return返回一個整數(shù)狀態(tài)碼0表示成功非0表示失敗。return和exit容易混return只是退出當前函數(shù)腳本還能繼續(xù)exit是直接終止整個腳本。在某個函數(shù)里判斷要不要讓整個腳本停下來就要分清楚用return還是exit。我一般是函數(shù)內部出錯且后續(xù)步驟依賴該函數(shù)的結果就在函數(shù)里exit 1讓腳本立刻失敗只是單一環(huán)節(jié)出錯、不影響整體就return非零值讓調用方自行處理。函數(shù)設計上還有一個經驗一個函數(shù)只做一件事函數(shù)名誠實描述行為。read_config作為一個函數(shù)就只負責讀取配置并校驗不把別的邏輯塞進來。這樣腳本讀起來像是一篇有目錄的文章而不是一團糾纏的線。4.2 退出碼與set -euo pipefail的核心策略每個命令執(zhí)行完都會留下一個退出碼0是成功1到255是各種失敗原因。在條件判斷和循環(huán)里shell就是靠退出碼來決定走向。$?保存著上一個命令的退出碼但它有個致命特點任何命令執(zhí)行都會覆蓋$?。你想檢查某個命令的結果必須立刻取值中間不能穿插任何其他命令。下面這個寫法就是典型的錯grep error app.log echo grep退出碼記錄到變量: $? if [ $? -eq 0 ]; then第一次$?還是grep的退出碼第二次$?已經是echo命令的了想判斷grep結果時早就不對了。正確做法是第一時間把退出碼存下來grep error app.log ret$? if [ $ret -eq 0 ]; thenset選項能大幅改變腳本的容錯行為。set -e表示任何一條命令返回非零就立刻退出腳本避免錯誤被掩蓋、腳本帶著錯誤狀態(tài)繼續(xù)跑出更多問題。初學者經常覺得set -e太敏感但正是這種敏感讓問題盡早暴露。set -u表示使用未定義變量時直接報錯退出能順手抓出很多變量名拼寫錯誤。set -o pipefail讓管道中任何一個環(huán)節(jié)失敗都被識別為管道失敗否則bash只關心管道最后一個命令的狀態(tài)前面環(huán)節(jié)悄悄掛了你都不知道。三個選項拼在一起set -euo pipefail就是我現(xiàn)在所有腳本開頭的標配。它們改變了腳本遇到錯誤時的默認反應從默默繼續(xù)變成大聲失敗。這個轉變對線上任務的意義非常大我自己是踩過腳本其實早就出錯但還在跑的虧之后才真正體會到這行配置的價值。也要說明set -e在某些場景下需要臨時關閉。比如你明確知道某條命令可能失敗且失敗是可以接受的可以用if cmd; then的寫法把它放在條件里這樣set -e不會干涉?；蛘哂胏md || true主動吞掉失敗狀態(tài)。但|| true相當于告訴讀者這行失敗無所謂所以要謹慎使用別讓該報的錯都被蒙混過關。4.3 trap清理與臨時文件安全管理腳本跑著跑著被中斷了留下的臨時文件、鎖文件怎么辦trap命令就是為這種場景準備的。trap code EXIT可以讓腳本在任何方式退出時都會執(zhí)行那段清理代碼無論是正常結束、被中斷還是報錯退出。我寫腳本時凡是創(chuàng)建了臨時目錄必配一句tmp_dir$(mktemp -d) trap rm -rf $tmp_dir EXITmktemp -d會在/tmp下生成一個隨機命名的目錄避免用固定路徑導致多個實例互相覆蓋也防止了路徑被其他用戶提前猜到帶來隱患。trap清理保證腳本就算中途掛了垃圾也能被帶走。單獨看rm -rf $tmp_dir這個命令還有一個細節(jié)變量要用雙引號包住否則目錄名里有空格時會拆成多個參數(shù)甚至可能誤刪不該刪的東西。關于rm -rf的風險后面安全部分還會展開。trap還可以監(jiān)聽信號trap echo 收到中斷信號開始收尾; exit 1 INT TERM讓腳本在被CtrlC時先做清理再退出。這種無論如何退出都先清理的思維是腳本健壯性的一個核心習慣建議把它內置到自己的腳本模板里。5. 實戰(zhàn)拆解一個日志自動清理腳本5.1 需求描述與功能拆分前面講了這么多理論現(xiàn)在用一個我真實場景里非常常見的例子把整個流程串起來。假設有一個業(yè)務日志目錄/data/app/logs里面每天生成一個以日期命名的.log文件還可能有子目錄。需求有三點刪除30天前的日志文件釋放磁盤空間刪除前記錄一份清理清單方便以后查賬如果目錄所在磁盤使用率超過80%輸出告警信息并留下一條醒目的記錄。這種需求如果直接寫三坨命令也能完成大部分功能但可讀性、安全性都差。按前面說的思路我先拆功能校驗目錄、執(zhí)行清理、記錄日志、檢查磁盤水位。每個功能一個函數(shù)主流程簡單清晰。5.2 完整腳本逐段解析先看完整代碼再逐段解釋關鍵處。這個腳本偏向通用教學你可以直接拿來改成本地路徑使用。#!/bin/bash # 功能日志目錄過期清理與磁盤水位檢查 # 用法./clean_logs.sh [保留天數(shù)] [目標目錄] set -euo pipefail LOG_DIR/data/app/logs KEEP_DAYS${1:-30} LIMIT80 CLEAN_LOG/var/log/clean_logs_history.log log_msg() { echo $(date %F %T) $* $CLEAN_LOG } check_dir() { if [ ! -d $LOG_DIR ]; then log_msg 目錄不存在: $LOG_DIR exit 1 fi } disk_usage() { local used used$(df $LOG_DIR | awk NR2 {print $5} | tr -d %) if [ $used -ge $LIMIT ]; then log_msg 磁盤使用率超限: ${used}% ${LIMIT}% echo 警告: 磁盤使用率已達 ${used}% fi } do_clean() { local file while IFS read -r file; do [ -f $file ] || continue log_msg 刪除過期日志: $file rm -f $file done (find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS -print0) } main() { check_dir do_clean disk_usage log_msg 清理任務完成保留天數(shù)${KEEP_DAYS} } main逐段來說。set -euo pipefail就是前面說的標配。其中-u在這里尤其重要因為腳本引用了KEEP_DAYS、LOG_DIR這類變量如果變量名寫錯或者賦值沒成功-u會立刻讓腳本報錯而不是用空值一路帶偏后面的邏輯。LOG_DIR和KEEP_DAYS是配置區(qū)。我把可變的配置集中在腳本頂部以后要改路徑或天數(shù)只動這幾行就行。KEEP_DAYS${1:-30}表示支持命令行參數(shù)指定天數(shù)不指定就默認30天。這種配置集中加參數(shù)覆蓋的模式很實用。log_msg函數(shù)把所有運行痕跡追加到CLEAN_LOG。日志統(tǒng)一記錄是運維腳本的底線出事后能回溯也是留痕思維的體現(xiàn)。函數(shù)里的$*會把所有參數(shù)合并成一行配合前面的日期時間戳記錄的信息就很完整了。check_dir先驗證目錄存在。在腳本一開頭就校驗前置條件是避免任務做到一半才發(fā)現(xiàn)環(huán)境不滿足的經典做法。disk_usage用df拿使用率再用awk取第二行的百分比字段用tr去掉百分號最后和LIMIT比較。這里一個細節(jié)是df的輸出第一行是標題NR2才是目標文件系統(tǒng)的數(shù)據行。do_clean是整個腳本的核心。find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS查找指定目錄下距離修改時間超過保留天數(shù)的.log文件。-mtime 30的意思是文件修改時間在30天之前。選項-print0讓find以null字符分隔輸出的文件名這是為了應對文件名里有空格或換行的極端情況。然后通過進程替換(...)把find的結果作為while循環(huán)的輸入這樣while循環(huán)跑在當前shell里不會遇到前面說的子shell變量丟失問題。循環(huán)體里先判斷[ -f $file ]再刪除主要是防止find結果因路徑變化已經失效避免把不存在路徑當普通參數(shù)處理。main函數(shù)把整個流程串起來腳本真正執(zhí)行的地方就一行main。這樣設計的好處是腳本的邏輯一目了然想單獨調試某個環(huán)節(jié)可以臨時注釋掉main里的某一項或者直接拿出某個函數(shù)單獨測試。5.3 接入crontab與運行驗證腳本寫好后用crontab -e編輯定時任務添加一行30 2 * * * /usr/local/bin/clean_logs.sh 30 /data/app/logs /dev/null 21這表示每天凌晨2點半執(zhí)行一次第一個30是保留天數(shù)。定時任務里有一個經典坑cron執(zhí)行環(huán)境非常精簡PATH可能不包含腳本依賴的命令路徑所以腳本里的命令最好寫全路徑或者調用時顯式帶上環(huán)境。我一般習慣在腳本里固定export PATH/usr/local/bin:/usr/bin:/bin避免cron環(huán)境下找不到命令。先手動執(zhí)行一遍確認退出碼為0再檢查CLEAN_LOG里有沒有正常記錄。然后用find手動驗證一下過期文件確實被清理了。最后再掛cron不要寫完就直接掛上萬一有bug定時任務會在凌晨悄悄幫你放大問題。6. 調試技巧與高頻避坑速查6.1 調試三板斧bash -x、set -x、關鍵節(jié)點輸出shell腳本出了問題怎么排查我用得最多的方法是bash -x script.sh直接以調試模式運行。這個模式下每條命令執(zhí)行前都會把展開后的實際命令打印到標準錯誤前面帶一個加號?？吹郊犹柡竺娴膶嶋H命令就能立刻發(fā)現(xiàn)變量展開是不是符合預期、某條命令是不是被拆成了兩條。比如變量沒加引號導致參數(shù)分裂在-x模式下會非常直觀地看到命令參數(shù)被拆開。腳本內部也可以用set -x開、set x關把調試范圍限制在某個區(qū)間echo 開始調試 set -x rm -f $file set x echo 調試結束這樣做可以避免整個腳本的輸出被調試信息淹沒。還有一種低技術含量但極有效的方法在關鍵節(jié)點加echo輸出。變量賦值后、分支進入前、循環(huán)每次迭代時各打一行帶標記的輸出比如echo DEBUG: file$file, count$count。配合bash -x基本能定位九成的邏輯問題。再有就是trap echo line:$LINENO, ret$? ERR每行出錯時自動打印行號和退出碼。這個對定位到底哪條命令掛了特別有幫助。需要留意ERR觸發(fā)和set -e、命令返回非零等條件有依賴關系實際使用中配合bash -x效果更好。6.2 高頻錯誤對照速查我整理了平時答疑時遇到最多的問題做成一個速查表能省不少排查時間。現(xiàn)象常見原因解決辦法執(zhí)行腳本提示Permission denied沒有執(zhí)行權限chmod x script.sh能執(zhí)行但報command not found文件名含特殊字符或CRLF換行用file查看格式dos2unix轉換變量值不對多出奇怪內容未加雙引號被shell分詞或擴展變量引用一律加雙引號if判斷總是走false方括號左右缺空格[ $a $b ]每個地方留空格循環(huán)后變量值沒變子shell邊界問題改用重定向或進程替換整數(shù)比較報語法錯誤用了 而不是-gt -lt數(shù)值比較用-eq -ne -gt -ltrm在某些文件上報參數(shù)過多find結果過多導致參數(shù)上限超限改用find -delete或分批處理腳本某個環(huán)節(jié)靜默失敗沒開啟set -e和pipefail腳本開頭加set -euo pipefail這里面CRLF換行的問題值得單獨說一句。在Windows上編輯過的腳本上傳到Linux文件每行末尾會帶著\r第一行shebang會變成#!/bin/bash\r系統(tǒng)會報bad interpreter錯誤。用file script.sh看一下顯示with CRLF line terminators就知道是這個原因。解決用sed -i s/\r$// script.sh或者dos2unix命令。養(yǎng)成在Linux環(huán)境里編輯腳本、或者給編輯器設置好換行符的習慣能從根上避開這個問題。6.3 隱蔽風險rm -rf、通配符展開、eval與臨時文件shell腳本因為可以直接執(zhí)行任意系統(tǒng)命令安全上的坑比其他語言更需要警惕。首當其沖的是rm -rf這類危險命令。如果變量沒設置好rm -rf $dir/里的dir是空字符串就會變成rm -rf /后果不堪設想。我的習慣是凡是涉及rm -rf先用[ -n $dir ]校驗變量非空再用set -u兜底并且在執(zhí)行前echo出完整命令供人工檢查。雖然這次寫的清理腳本用的是rm -f不帶-r但任何刪除操作都值得同樣的謹慎。另一個隱蔽風險是變量里的通配符展開。如果文件名里帶有*號不加引號的使用會把星號按通配符展開可能展開成一堆文件路徑。這個問題在讀取外部數(shù)據來源時尤其值得注意外部數(shù)據不可信你的引號就是防線。凡是對變量內容不確定默認加雙引號這一條能擋住一大片問題。eval命令要盡量少用。eval會先把字符串拼接成命令再執(zhí)行等于允許外部輸入直接變成命令注入風險極高。在我處理的場景中絕大多數(shù)eval需求都可以通過關聯(lián)數(shù)組、case分支或函數(shù)映射解決沒有必要用eval。如果你確實繞不開至少確保eval的參數(shù)完全由腳本內部受控內容構成絕不讓外部輸入直接進eval。臨時文件的安全也要注意。腳本里別用固定的/tmp/my_temp_file這種路徑多個實例同時跑會互相覆蓋別人也可能猜到路徑做手腳。統(tǒng)一用mktemp或mktemp -d生成隨機路徑用完配合trap清理。關于腳本安全我的總原則是輸入嚴格校驗、輸出路徑明確、權限最小化、危險操作前置檢查。這些習慣不復雜但能在關鍵時候把損失控制住。7. 腳本長期維護的幾點習慣7.1 命名、注釋與版本管理腳本命名要一看就知道用途clean_logs.sh、backup_mysql.sh、check_disk.sh都比test1.sh、new2.sh強一百倍。命名里建議包含動詞表達做什么而不是是什么。腳本存放到統(tǒng)一目錄比如~/bin或/usr/local/bin按功能分目錄更清晰比如scripts/clean、scripts/backup、scripts/monitor。注釋不需要泛濫但文件頭的用途說明、每個函數(shù)的輸入輸出說明、以及關鍵代碼行中為什么不這樣寫的說明值得認真寫。我最重視的是為什么的注釋一行代碼解釋不了為什么需要這段邏輯而這里不直接用rm是因為...這種注釋能幫半年后的自己快速回憶當初的決策。版本管理方面哪怕只是個人腳本也建議納入git。腳本會不斷演進能回溯每一次改動、看到什么時候改了什么排查線上問題時價值巨大。如果嫌每次提交麻煩可以只在腳本改動達到一定規(guī)模時提交但至少要保留一份修訂記錄比如在文件頭加一行修改歷史2024-01-01 增加磁盤水位檢查。我在自己的環(huán)境里是喜歡都用git管理的腳本庫一個倉庫分支按環(huán)境區(qū)分發(fā)布用標簽。長期下來腳本庫從一坨快看不懂的文件變成了有歷史有說明的工具集維護成本明顯下降。7.2 冪等設計與鎖文件好的腳本應該可以重復運行而不產生壞結果這叫做冪等性。舉例說初始化目錄的腳本mkdir -p /data/app/logs無論執(zhí)行多少次都不報錯但如果是清空目錄的腳本不加判斷跑兩遍可能就刪掉了不該刪的東西。設計腳本時問自己一個問題同一個腳本跑兩遍、跑十遍結果應該一樣嗎如果答案應該是一樣那就要確保關鍵步驟是冪等的。常見做法包括創(chuàng)建目錄用mkdir -p而不是先判斷再加mkdir寫文件前先檢查是否已存在或先備份刪除操作前先確認目標存在且符合預期涉及狀態(tài)變更的步驟用鎖文件避免重復執(zhí)行。鎖文件可以簡單用flock實現(xiàn)exec 9${script_dir}/.lock flock -n 9 || { echo 腳本已在運行; exit 1; }這樣能防止同一個腳本并發(fā)執(zhí)行互相干擾。定時任務和手動任務指向同一個腳本時這種做法尤其重要。7.3 寫給下一個自己最后聊點個人的體會。腳本這行功夫不是把語法背熟就完了真正值錢的是踩坑之后的判斷力知道什么場景該寫腳本、什么場景不該上知道哪幾行代碼在運行時最容易出問題知道出問題后第一步應該看哪里。這些能力沒有捷徑就是多寫多踩多總結。我現(xiàn)在的習慣是每次踩到一個不常見的坑就在自己的筆記里記一筆包括現(xiàn)象、原因、解決過程。久而久之這本筆記就變成了自己的排障字典。這也正是我寫這第十六篇筆記的初衷很多經驗不記下來三個月后我可能還是得靠重新踩坑才能想起來。如果你剛開始學shell腳本我的建議很樸素從改造自己昨天手工敲過的命令開始今天把它寫成腳本明天給腳本加參數(shù)和錯誤處理后天再試著用函數(shù)重構一遍。不用特意去找復雜案例你日常的重復勞動就是最好的練習題。一次把一個小的需求做扎實腳本能力就是這么積累起來的。 Shell腳本實戰(zhàn)：從踩坑到高效自動化運維
從事Linux運維和開發(fā)這些年shell腳本是我每天都會碰的東西。做日志切割、批量改文件、寫定時任務、數(shù)據同步、環(huán)境初始化一件件看起來雞毛蒜皮的小事最后都是靠腳本把人力省下來的。這是我自己筆記的第十六篇前面寫過系統(tǒng)啟動、權限、磁盤、網絡這些基礎內容這篇專門聊聊shell腳本把我這些年踩過的坑和覺得有價值的寫法一次性梳理出來希望能幫正在學腳本的讀者少走幾步彎路。這篇內容不打算從什么是變量這種教科書概念開始而是直接以實戰(zhàn)視角切入什么時候該寫腳本、腳本骨架怎么搭、核心語法怎么用才不出錯、完整案例怎么落地、出了問題怎么排查。適合已經會敲基本命令、想把零散命令變成可復用工具的讀者如果你是完全零基礎可以先拿著基本命令練幾遍再來看這篇效果會更好。1. 什么時候真正需要動手寫腳本1.1 腳本最擅長解決的幾類問題先說實話不是所有事情都值得寫成腳本。我自己判斷的標準很簡單這件事是不是要重復做兩次以上是不是需要多個命令配合才能完成如果答案都是肯定的那基本就該寫了。最常見的場景我列一下批量操作類幾十臺機器上收集信息、幾百個文件統(tǒng)一改名、批量壓縮解壓。手工敲一條條命令又累又容易漏腳本跑一遍還能留下輸出日志。定時任務類日志清理、數(shù)據備份、臨時文件歸檔、健康檢查告警。cron加腳本是絕配腳本負責邏輯cron負責定時觸發(fā)。部署與初始化類新機器裝環(huán)境、初始化配置、重啟服務。這類操作步驟多且有固定順序寫成腳本后可以反復執(zhí)行也方便在出問題時快速重來。格式轉換與數(shù)據處理把CSV轉成另一種格式、從日志里面提取關鍵字段、批量替換文件內容。配合awk、sed、grep這些工具一個瘦腳本就能解決很多所謂大數(shù)據需求的土辦法方案。我遇到最多的是日志相關。比如業(yè)務系統(tǒng)每天產生的日志文件按照日期命名超過30天的需要刪除磁盤空間到80%需要告警。這種需求用手工做根本不現(xiàn)實定時跑一個腳本才是正解。后面我會把這個完整腳本展開講。即使是臨時性任務只要我開始覺得這串命令要重復手敲兩遍也會順手寫成腳本。寫的時候可能只花三分鐘但后面再遇到類似需求把腳本翻出來改兩行就能用。腳本庫就是這么一點一點攢出來的。1.2 別把腳本當萬能鑰匙shell腳本也不是沒有短板。遇到下面這幾類情況我建議換個工具而不是硬撐。一是性能敏感的大數(shù)據處理。比如幾GB的日志要算統(tǒng)計指標shell里一層層循環(huán)會慢到讓人懷疑人生這時候用Python、Go甚至直接上SQL都更合適。shell適合做膠水層面的組織和協(xié)調不適合做重計算。二是邏輯特別復雜的流程。判斷分支多了、狀態(tài)多了、需要復雜數(shù)據結構的場景shell寫起來會很痛苦調試也費勁。腳本里出現(xiàn)幾十行嵌套if基本就是該重構或者換更合適語言重寫的信號。三是跨平臺要求高的場景。雖然bash在各種Linux發(fā)行版上都通用但有些命令在不同發(fā)行版上行為略有差別macOS自帶的是舊版bashWindows上更是另一套。如果腳本要在完全不同的環(huán)境里跑要么用Python這類跨平臺解釋器要么在腳本里做足兼容判斷。我的經驗是能用標準命令組合解決的就用腳本感覺腳本寫起來已經很別扭了果斷換語言。工具選對了后面維護的成本才會低。1.3 動手前先想清楚三個問題寫一個腳本之前先花兩分鐘想三件事輸入是什么、輸出是什么、中間有哪些約束。輸入可能是配置文件、命令行參數(shù)或環(huán)境變量輸出可能是處理后的文件、日志記錄或一個退出碼約束包括運行權限、運行時間窗口、磁盤空間上限等。想清楚這三件事腳本的結構基本就出來了。然后遵循一個原則一個腳本只干一件事。把功能拆成函數(shù)每個函數(shù)只做它負責的那部分。這樣做的好處是定位問題快、復用方便也方便以后把腳本拆成更細的模塊。我早期寫腳本總是一個腳本解決所有問題結果腳本越來越長改一個邏輯就動到全局線上出了故障排查得像考古。吃過虧以后才養(yǎng)成先拆功能、再動手寫的習慣。2. 腳本骨架搭建與變量引用的關鍵細節(jié)2.1 shebang、執(zhí)行權限和首行配置一個普通文本文件要讓系統(tǒng)當成腳本執(zhí)行需要兩個條件第一行以#!開頭指定解釋器并且文件要有執(zhí)行權限。第一行寫#!/bin/bash還是#!/usr/bin/env bash兩者都能用但意義不同。直接寫#!/bin/bash是明確指定解釋器路徑性能稍好兼容性也更容易預料。寫#!/usr/bin/env bash是先找到bash所在路徑再執(zhí)行在bash不在標準位置的系統(tǒng)上更靈活但env本身如果找不到也會帶來問題。我自己在服務器上習慣直接寫#!/bin/bash因為標準發(fā)行版上bash基本都在這個位置少一層解析也更穩(wěn)。執(zhí)行權限用chmod x script.sh加上。這一步很多人忽略導致明明腳本沒問題卻提示Permission denied。另外如果在當前目錄運行腳本要寫成./script.sh而不是script.sh因為當前目錄通常不在PATH環(huán)境變量里。這個踩坑率極高尤其是剛從Windows轉到Linux環(huán)境的讀者。首行配置我還建議加兩樣東西一是文件頭的注釋寫明腳本用途、創(chuàng)建時間和維護人二是set選項。雖然set選項后面詳細講但我現(xiàn)在寫任何腳本開頭幾乎固定是#!/bin/bash # 功能xxxx # 創(chuàng)建2024-xx-xx set -euo pipefailset -euo pipefail這一行帶來的變化我后面詳細說先記住它能讓腳本在出錯時立刻暴露問題而不是帶病往下跑。2.2 變量取值與引號使用的門道變量賦值在shell里看似簡單坑全藏在細節(jié)中。賦值語句等號兩邊不能有空格寫成name 張三會變成執(zhí)行命令name直接報command not found。這個錯誤我見新人踩過無數(shù)次。取變量值用$name但更嚴謹?shù)膶懛ㄊ?{name}。兩者差別在變量名后面緊跟其他字符時體現(xiàn)出來echo $name_file會把name_file當成一個變量名而echo ${name}_file才是取name變量的值再加下劃線和file。凡是變量名邊界不清晰的場景一律用${}包裹這是一個讓腳本更清晰、更安全的好習慣。引號的使用是shell腳本最容易出問題的點。什么時候用雙引號什么時候不用規(guī)則其實很明確如果變量的值可能包含空格、通配符或其他特殊字符并且你希望它作為一個整體被處理就必須加雙引號。比如file_path/data/logs/app 2024.log if [ -f $file_path ]; then echo 文件存在 fi如果這里不加雙引號[ -f $file_path ]會被展開成[ -f /data/logs/app 2024.log ]test命令會因為參數(shù)個數(shù)不對直接報語法錯誤。雙引號的作用就是給整個值包一層不讓shell把里面的空格當成分隔符。還有一種情況是變量的值來源不可控比如讀取外部文件內容、命令輸出的結果這時候雙引號尤其重要。不加雙引號的話文件里如果有分號、感嘆號、星號之類的內容shell會做各種展開輕則結果不對重則執(zhí)行了本不該執(zhí)行的命令。我在這上面栽過跟頭一個讀取文件內容后再拼成命令發(fā)送的腳本文件里恰巧有分號結果一行原本正常的命令被拆成了兩條。從那以后凡是非我手寫的字符串默認一律加雙引號處理。命令替換是另一個常用特性$(command)會執(zhí)行命令并把輸出作為值。比如拿今天日期today$(date %F)。這里我建議優(yōu)先用$()而不是反引號因為反引號在處理嵌套時容易出錯$()可以嵌套可讀性也更好。注意命令替換的結果如果有換行符賦值給變量后會保留echo出來可能看到多行這在處理命令輸出時要心里有數(shù)。2.3 位置參數(shù)與入參檢查腳本接收外部輸入最常見的是位置參數(shù)$1、$2這種。比如./backup.sh /data/mysql /backup腳本里$1就是/data/mysql$2就是/backup。$#表示參數(shù)個數(shù)$表示所有參數(shù)并且每個參數(shù)獨立$也表示所有參數(shù)但視為一個整體。遍歷參數(shù)時應該用for arg in $而不是$這樣才能正確處理帶空格的參數(shù)值。腳本里的關鍵參數(shù)我習慣加一道檢查避免用戶忘了傳參導致腳本在后面某個莫名其妙的位置報錯。典型寫法if [ $# -lt 2 ]; then echo 用法: $0 源目錄 備份目錄 exit 1 fi這樣做的好處是錯誤信息明確而不是腳本跑了一大半才因為找不到文件而失敗。exit 1返回非零退出碼調用方可以據此判斷腳本執(zhí)行失敗。有時候參數(shù)是可選的需要默認值。shell的參數(shù)展開語法能直接處理${var:-默認值}表示var沒設置或為空時使用默認值。比如日志保留天數(shù)支持通過參數(shù)指定不指定就默認30天keep_days${1:-30}。這樣腳本既靈活又穩(wěn)妥。類似地${var:默認值}不但取默認值還給變量賦值${var:?提示信息}在變量為空時直接退出并輸出提示適合強制要求參數(shù)的場景。3. 條件判斷與循環(huán)的實戰(zhàn)細節(jié)3.1 條件測試寫法單中括號和雙中括號怎么選shell里做判斷本質上是運行一個test命令并根據它的退出碼決定分支。if [ ... ]中的方括號其實是test命令的另一種寫法所以方括號兩邊必須有空格[ $a $b ]寫成[ $a$b ]就會出錯因為shell把整個字符串當成了一個參數(shù)?，F(xiàn)代bash里更推薦用雙中括號[[ ... ]]。它是bash內置的關鍵詞支持更豐富的表達式比如和都可以用支持正則匹配也支持和||這種邏輯運算符。最關鍵的是在[[ ]]內部變量即使不加雙引號也不會被錯誤分詞對新手友好得多。我的建議是既然用的是bash直接統(tǒng)一用[[ ]]不要再拿單中括號去踩那些邊邊角角的坑。文件判斷操作符要記牢-f判斷是不是普通文件-d判斷是不是目錄-e判斷路徑是否存在-r、-w、-x判斷讀、寫、執(zhí)行權限-z和-n判斷字符串為空或非空。-nt和-ot可以比較文件的修改時間新舊在增量備份場景里很好用。數(shù)值比較用-eq、-ne、-gt、-lt而不是和因為在shell里是重定向符號寫錯會引發(fā)文件重定向非常隱蔽。邏輯判斷的寫法在[[ ]]里直接用和||if [[ -f $file -r $file ]]; then。在單中括號里要用-a和-o再加上各種轉義可讀性和安全性都差。所以堅持用[[ ]]能讓代碼干凈很多。3.2 for、while、until在什么場景下各司其職for循環(huán)適合遍歷已知列表遍歷一組文件、一組主機名、一組參數(shù)。最典型的是遍歷當前目錄下的所有txt文件for f in *.txt; do echo 處理文件: $f done注意*.txt在這里會先被shell展開成文件列表如果目錄里沒有匹配的文件展開結果會是字面的*.txt循環(huán)還是會執(zhí)行一次所以最好先判斷文件是否存在再進循環(huán)。遍歷時如果文件名有空格for f in *.txt這種寫法會出問題因為空格會被當成列表分隔。處理方法是用find配合while readfind . -name *.txt -print0 | while IFS read -r -d f; do echo 處理文件: $f done-print0把文件名以null分隔-d 讓read也按null分隔讀取。這個寫法看著繁瑣但它在處理帶空格、帶換行的文件名時百分之百可靠是處理任意文件名最穩(wěn)妥的方式。while循環(huán)適合條件驅動的場景讀文件直到文件結束、等待某個條件成立、消費某個隊列。最常見的while讀文件寫法while IFS read -r line; do echo $line done input.txtIFS防止行首行尾的空白被trim掉-r防止反斜杠被解釋 input.txt把文件作為循環(huán)的輸入。這種寫法比for i in $(cat input.txt)安全得多因為for配合$(cat)會把文件按空格、按換行全部分裂一遍文件內容稍微有點特殊字符就亂套了。until循環(huán)和while結構一樣只是條件為假時執(zhí)行。實際用得少但偶爾用來等待某個服務就緒還挺順手until nc -z 127.0.0.1 3306; do sleep 1; done一直等到數(shù)據庫端口能連通。循環(huán)里break可以提前跳出continue進入下一輪是兩個常用的控制指令不要忘記。3.3 管道、子shell與循環(huán)變量丟失問題這個問題我必須單獨提因為它坑過的絕對不止我一個人在管道后面接while循環(huán)循環(huán)內對變量的修改在循環(huán)結束后會丟失?？催@個經典例子count0 echo -e a\nb\nc | while read line; do count$((count 1)) done echo $count輸出是0而不是3。原因在于管道會讓while循環(huán)跑在一個子shell進程里子shell里的變量修改不會傳回父shell。我第一次遇到時百思不得其解查來查去才發(fā)現(xiàn)是shell的設計使然。解決思路有三種。第一種把輸入重定向而不是用管道while read line; do count$((count 1)) done (echo -e a\nb\nc)進程替換(command)產生的輸入通過重定向進入循環(huán)循環(huán)本身還在當前shell里運行變量修改就能保留。第二種是把結果寫到文件再讀出來。第三種是把處理邏輯封裝成函數(shù)后用輸出捕獲結果但本質上還是在子shell里靠的是函數(shù)輸出而非變量傳遞。這類子shell邊界問題在管道、find -exec、括號子shell里都會出現(xiàn)。遇到變量值詭異消失的現(xiàn)象第一反應就是檢查是不是跨越了子shell邊界。排查方法也很簡單在關鍵位置加echo輸出中間值看看循環(huán)內和循環(huán)外的值是否一致不一致基本就是邊界問題。4. 函數(shù)設計、退出碼與腳本健壯性4.1 用函數(shù)拆骨架local變量防污染腳本一長組織方式就成了大問題。我現(xiàn)在的習慣是腳本主體只保留流程調度真正的邏輯全部放進函數(shù)。函數(shù)定義用function name() {}或者直接name() {}都可以我傾向不帶function關鍵字和POSIX兼容性更好。函數(shù)里要特別注意變量的作用域。默認情況下函數(shù)里賦值的變量是全局的會污染腳本其他部分。所以凡是函數(shù)內部的臨時變量一律用local聲明local tmp_file/tmp/xxx。這能避免函數(shù)間因為同一個變量名互相影響排查問題時也清楚每個變量的歸屬。這個習慣和寫代碼時不讓函數(shù)偷偷改全局狀態(tài)是同一個道理。函數(shù)內用return返回一個整數(shù)狀態(tài)碼0表示成功非0表示失敗。return和exit容易混return只是退出當前函數(shù)腳本還能繼續(xù)exit是直接終止整個腳本。在某個函數(shù)里判斷要不要讓整個腳本停下來就要分清楚用return還是exit。我一般是函數(shù)內部出錯且后續(xù)步驟依賴該函數(shù)的結果就在函數(shù)里exit 1讓腳本立刻失敗只是單一環(huán)節(jié)出錯、不影響整體就return非零值讓調用方自行處理。函數(shù)設計上還有一個經驗一個函數(shù)只做一件事函數(shù)名誠實描述行為。read_config作為一個函數(shù)就只負責讀取配置并校驗不把別的邏輯塞進來。這樣腳本讀起來像是一篇有目錄的文章而不是一團糾纏的線。4.2 退出碼與set -euo pipefail的核心策略每個命令執(zhí)行完都會留下一個退出碼0是成功1到255是各種失敗原因。在條件判斷和循環(huán)里shell就是靠退出碼來決定走向。$?保存著上一個命令的退出碼但它有個致命特點任何命令執(zhí)行都會覆蓋$?。你想檢查某個命令的結果必須立刻取值中間不能穿插任何其他命令。下面這個寫法就是典型的錯grep error app.log echo grep退出碼記錄到變量: $? if [ $? -eq 0 ]; then第一次$?還是grep的退出碼第二次$?已經是echo命令的了想判斷grep結果時早就不對了。正確做法是第一時間把退出碼存下來grep error app.log ret$? if [ $ret -eq 0 ]; thenset選項能大幅改變腳本的容錯行為。set -e表示任何一條命令返回非零就立刻退出腳本避免錯誤被掩蓋、腳本帶著錯誤狀態(tài)繼續(xù)跑出更多問題。初學者經常覺得set -e太敏感但正是這種敏感讓問題盡早暴露。set -u表示使用未定義變量時直接報錯退出能順手抓出很多變量名拼寫錯誤。set -o pipefail讓管道中任何一個環(huán)節(jié)失敗都被識別為管道失敗否則bash只關心管道最后一個命令的狀態(tài)前面環(huán)節(jié)悄悄掛了你都不知道。三個選項拼在一起set -euo pipefail就是我現(xiàn)在所有腳本開頭的標配。它們改變了腳本遇到錯誤時的默認反應從默默繼續(xù)變成大聲失敗。這個轉變對線上任務的意義非常大我自己是踩過腳本其實早就出錯但還在跑的虧之后才真正體會到這行配置的價值。也要說明set -e在某些場景下需要臨時關閉。比如你明確知道某條命令可能失敗且失敗是可以接受的可以用if cmd; then的寫法把它放在條件里這樣set -e不會干涉?；蛘哂胏md || true主動吞掉失敗狀態(tài)。但|| true相當于告訴讀者這行失敗無所謂所以要謹慎使用別讓該報的錯都被蒙混過關。4.3 trap清理與臨時文件安全管理腳本跑著跑著被中斷了留下的臨時文件、鎖文件怎么辦trap命令就是為這種場景準備的。trap code EXIT可以讓腳本在任何方式退出時都會執(zhí)行那段清理代碼無論是正常結束、被中斷還是報錯退出。我寫腳本時凡是創(chuàng)建了臨時目錄必配一句tmp_dir$(mktemp -d) trap rm -rf $tmp_dir EXITmktemp -d會在/tmp下生成一個隨機命名的目錄避免用固定路徑導致多個實例互相覆蓋也防止了路徑被其他用戶提前猜到帶來隱患。trap清理保證腳本就算中途掛了垃圾也能被帶走。單獨看rm -rf $tmp_dir這個命令還有一個細節(jié)變量要用雙引號包住否則目錄名里有空格時會拆成多個參數(shù)甚至可能誤刪不該刪的東西。關于rm -rf的風險后面安全部分還會展開。trap還可以監(jiān)聽信號trap echo 收到中斷信號開始收尾; exit 1 INT TERM讓腳本在被CtrlC時先做清理再退出。這種無論如何退出都先清理的思維是腳本健壯性的一個核心習慣建議把它內置到自己的腳本模板里。5. 實戰(zhàn)拆解一個日志自動清理腳本5.1 需求描述與功能拆分前面講了這么多理論現(xiàn)在用一個我真實場景里非常常見的例子把整個流程串起來。假設有一個業(yè)務日志目錄/data/app/logs里面每天生成一個以日期命名的.log文件還可能有子目錄。需求有三點刪除30天前的日志文件釋放磁盤空間刪除前記錄一份清理清單方便以后查賬如果目錄所在磁盤使用率超過80%輸出告警信息并留下一條醒目的記錄。這種需求如果直接寫三坨命令也能完成大部分功能但可讀性、安全性都差。按前面說的思路我先拆功能校驗目錄、執(zhí)行清理、記錄日志、檢查磁盤水位。每個功能一個函數(shù)主流程簡單清晰。5.2 完整腳本逐段解析先看完整代碼再逐段解釋關鍵處。這個腳本偏向通用教學你可以直接拿來改成本地路徑使用。#!/bin/bash # 功能日志目錄過期清理與磁盤水位檢查 # 用法./clean_logs.sh [保留天數(shù)] [目標目錄] set -euo pipefail LOG_DIR/data/app/logs KEEP_DAYS${1:-30} LIMIT80 CLEAN_LOG/var/log/clean_logs_history.log log_msg() { echo $(date %F %T) $* $CLEAN_LOG } check_dir() { if [ ! -d $LOG_DIR ]; then log_msg 目錄不存在: $LOG_DIR exit 1 fi } disk_usage() { local used used$(df $LOG_DIR | awk NR2 {print $5} | tr -d %) if [ $used -ge $LIMIT ]; then log_msg 磁盤使用率超限: ${used}% ${LIMIT}% echo 警告: 磁盤使用率已達 ${used}% fi } do_clean() { local file while IFS read -r file; do [ -f $file ] || continue log_msg 刪除過期日志: $file rm -f $file done (find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS -print0) } main() { check_dir do_clean disk_usage log_msg 清理任務完成保留天數(shù)${KEEP_DAYS} } main逐段來說。set -euo pipefail就是前面說的標配。其中-u在這里尤其重要因為腳本引用了KEEP_DAYS、LOG_DIR這類變量如果變量名寫錯或者賦值沒成功-u會立刻讓腳本報錯而不是用空值一路帶偏后面的邏輯。LOG_DIR和KEEP_DAYS是配置區(qū)。我把可變的配置集中在腳本頂部以后要改路徑或天數(shù)只動這幾行就行。KEEP_DAYS${1:-30}表示支持命令行參數(shù)指定天數(shù)不指定就默認30天。這種配置集中加參數(shù)覆蓋的模式很實用。log_msg函數(shù)把所有運行痕跡追加到CLEAN_LOG。日志統(tǒng)一記錄是運維腳本的底線出事后能回溯也是留痕思維的體現(xiàn)。函數(shù)里的$*會把所有參數(shù)合并成一行配合前面的日期時間戳記錄的信息就很完整了。check_dir先驗證目錄存在。在腳本一開頭就校驗前置條件是避免任務做到一半才發(fā)現(xiàn)環(huán)境不滿足的經典做法。disk_usage用df拿使用率再用awk取第二行的百分比字段用tr去掉百分號最后和LIMIT比較。這里一個細節(jié)是df的輸出第一行是標題NR2才是目標文件系統(tǒng)的數(shù)據行。do_clean是整個腳本的核心。find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS查找指定目錄下距離修改時間超過保留天數(shù)的.log文件。-mtime 30的意思是文件修改時間在30天之前。選項-print0讓find以null字符分隔輸出的文件名這是為了應對文件名里有空格或換行的極端情況。然后通過進程替換(...)把find的結果作為while循環(huán)的輸入這樣while循環(huán)跑在當前shell里不會遇到前面說的子shell變量丟失問題。循環(huán)體里先判斷[ -f $file ]再刪除主要是防止find結果因路徑變化已經失效避免把不存在路徑當普通參數(shù)處理。main函數(shù)把整個流程串起來腳本真正執(zhí)行的地方就一行main。這樣設計的好處是腳本的邏輯一目了然想單獨調試某個環(huán)節(jié)可以臨時注釋掉main里的某一項或者直接拿出某個函數(shù)單獨測試。5.3 接入crontab與運行驗證腳本寫好后用crontab -e編輯定時任務添加一行30 2 * * * /usr/local/bin/clean_logs.sh 30 /data/app/logs /dev/null 21這表示每天凌晨2點半執(zhí)行一次第一個30是保留天數(shù)。定時任務里有一個經典坑cron執(zhí)行環(huán)境非常精簡PATH可能不包含腳本依賴的命令路徑所以腳本里的命令最好寫全路徑或者調用時顯式帶上環(huán)境。我一般習慣在腳本里固定export PATH/usr/local/bin:/usr/bin:/bin避免cron環(huán)境下找不到命令。先手動執(zhí)行一遍確認退出碼為0再檢查CLEAN_LOG里有沒有正常記錄。然后用find手動驗證一下過期文件確實被清理了。最后再掛cron不要寫完就直接掛上萬一有bug定時任務會在凌晨悄悄幫你放大問題。6. 調試技巧與高頻避坑速查6.1 調試三板斧bash -x、set -x、關鍵節(jié)點輸出shell腳本出了問題怎么排查我用得最多的方法是bash -x script.sh直接以調試模式運行。這個模式下每條命令執(zhí)行前都會把展開后的實際命令打印到標準錯誤前面帶一個加號?？吹郊犹柡竺娴膶嶋H命令就能立刻發(fā)現(xiàn)變量展開是不是符合預期、某條命令是不是被拆成了兩條。比如變量沒加引號導致參數(shù)分裂在-x模式下會非常直觀地看到命令參數(shù)被拆開。腳本內部也可以用set -x開、set x關把調試范圍限制在某個區(qū)間echo 開始調試 set -x rm -f $file set x echo 調試結束這樣做可以避免整個腳本的輸出被調試信息淹沒。還有一種低技術含量但極有效的方法在關鍵節(jié)點加echo輸出。變量賦值后、分支進入前、循環(huán)每次迭代時各打一行帶標記的輸出比如echo DEBUG: file$file, count$count。配合bash -x基本能定位九成的邏輯問題。再有就是trap echo line:$LINENO, ret$? ERR每行出錯時自動打印行號和退出碼。這個對定位到底哪條命令掛了特別有幫助。需要留意ERR觸發(fā)和set -e、命令返回非零等條件有依賴關系實際使用中配合bash -x效果更好。6.2 高頻錯誤對照速查我整理了平時答疑時遇到最多的問題做成一個速查表能省不少排查時間。現(xiàn)象常見原因解決辦法執(zhí)行腳本提示Permission denied沒有執(zhí)行權限chmod x script.sh能執(zhí)行但報command not found文件名含特殊字符或CRLF換行用file查看格式dos2unix轉換變量值不對多出奇怪內容未加雙引號被shell分詞或擴展變量引用一律加雙引號if判斷總是走false方括號左右缺空格[ $a $b ]每個地方留空格循環(huán)后變量值沒變子shell邊界問題改用重定向或進程替換整數(shù)比較報語法錯誤用了 而不是-gt -lt數(shù)值比較用-eq -ne -gt -ltrm在某些文件上報參數(shù)過多find結果過多導致參數(shù)上限超限改用find -delete或分批處理腳本某個環(huán)節(jié)靜默失敗沒開啟set -e和pipefail腳本開頭加set -euo pipefail這里面CRLF換行的問題值得單獨說一句。在Windows上編輯過的腳本上傳到Linux文件每行末尾會帶著\r第一行shebang會變成#!/bin/bash\r系統(tǒng)會報bad interpreter錯誤。用file script.sh看一下顯示with CRLF line terminators就知道是這個原因。解決用sed -i s/\r$// script.sh或者dos2unix命令。養(yǎng)成在Linux環(huán)境里編輯腳本、或者給編輯器設置好換行符的習慣能從根上避開這個問題。6.3 隱蔽風險rm -rf、通配符展開、eval與臨時文件shell腳本因為可以直接執(zhí)行任意系統(tǒng)命令安全上的坑比其他語言更需要警惕。首當其沖的是rm -rf這類危險命令。如果變量沒設置好rm -rf $dir/里的dir是空字符串就會變成rm -rf /后果不堪設想。我的習慣是凡是涉及rm -rf先用[ -n $dir ]校驗變量非空再用set -u兜底并且在執(zhí)行前echo出完整命令供人工檢查。雖然這次寫的清理腳本用的是rm -f不帶-r但任何刪除操作都值得同樣的謹慎。另一個隱蔽風險是變量里的通配符展開。如果文件名里帶有*號不加引號的使用會把星號按通配符展開可能展開成一堆文件路徑。這個問題在讀取外部數(shù)據來源時尤其值得注意外部數(shù)據不可信你的引號就是防線。凡是對變量內容不確定默認加雙引號這一條能擋住一大片問題。eval命令要盡量少用。eval會先把字符串拼接成命令再執(zhí)行等于允許外部輸入直接變成命令注入風險極高。在我處理的場景中絕大多數(shù)eval需求都可以通過關聯(lián)數(shù)組、case分支或函數(shù)映射解決沒有必要用eval。如果你確實繞不開至少確保eval的參數(shù)完全由腳本內部受控內容構成絕不讓外部輸入直接進eval。臨時文件的安全也要注意。腳本里別用固定的/tmp/my_temp_file這種路徑多個實例同時跑會互相覆蓋別人也可能猜到路徑做手腳。統(tǒng)一用mktemp或mktemp -d生成隨機路徑用完配合trap清理。關于腳本安全我的總原則是輸入嚴格校驗、輸出路徑明確、權限最小化、危險操作前置檢查。這些習慣不復雜但能在關鍵時候把損失控制住。7. 腳本長期維護的幾點習慣7.1 命名、注釋與版本管理腳本命名要一看就知道用途clean_logs.sh、backup_mysql.sh、check_disk.sh都比test1.sh、new2.sh強一百倍。命名里建議包含動詞表達做什么而不是是什么。腳本存放到統(tǒng)一目錄比如~/bin或/usr/local/bin按功能分目錄更清晰比如scripts/clean、scripts/backup、scripts/monitor。注釋不需要泛濫但文件頭的用途說明、每個函數(shù)的輸入輸出說明、以及關鍵代碼行中為什么不這樣寫的說明值得認真寫。我最重視的是為什么的注釋一行代碼解釋不了為什么需要這段邏輯而這里不直接用rm是因為...這種注釋能幫半年后的自己快速回憶當初的決策。版本管理方面哪怕只是個人腳本也建議納入git。腳本會不斷演進能回溯每一次改動、看到什么時候改了什么排查線上問題時價值巨大。如果嫌每次提交麻煩可以只在腳本改動達到一定規(guī)模時提交但至少要保留一份修訂記錄比如在文件頭加一行修改歷史2024-01-01 增加磁盤水位檢查。我在自己的環(huán)境里是喜歡都用git管理的腳本庫一個倉庫分支按環(huán)境區(qū)分發(fā)布用標簽。長期下來腳本庫從一坨快看不懂的文件變成了有歷史有說明的工具集維護成本明顯下降。7.2 冪等設計與鎖文件好的腳本應該可以重復運行而不產生壞結果這叫做冪等性。舉例說初始化目錄的腳本mkdir -p /data/app/logs無論執(zhí)行多少次都不報錯但如果是清空目錄的腳本不加判斷跑兩遍可能就刪掉了不該刪的東西。設計腳本時問自己一個問題同一個腳本跑兩遍、跑十遍結果應該一樣嗎如果答案應該是一樣那就要確保關鍵步驟是冪等的。常見做法包括創(chuàng)建目錄用mkdir -p而不是先判斷再加mkdir寫文件前先檢查是否已存在或先備份刪除操作前先確認目標存在且符合預期涉及狀態(tài)變更的步驟用鎖文件避免重復執(zhí)行。鎖文件可以簡單用flock實現(xiàn)exec 9${script_dir}/.lock flock -n 9 || { echo 腳本已在運行; exit 1; }這樣能防止同一個腳本并發(fā)執(zhí)行互相干擾。定時任務和手動任務指向同一個腳本時這種做法尤其重要。7.3 寫給下一個自己最后聊點個人的體會。腳本這行功夫不是把語法背熟就完了真正值錢的是踩坑之后的判斷力知道什么場景該寫腳本、什么場景不該上知道哪幾行代碼在運行時最容易出問題知道出問題后第一步應該看哪里。這些能力沒有捷徑就是多寫多踩多總結。我現(xiàn)在的習慣是每次踩到一個不常見的坑就在自己的筆記里記一筆包括現(xiàn)象、原因、解決過程。久而久之這本筆記就變成了自己的排障字典。這也正是我寫這第十六篇筆記的初衷很多經驗不記下來三個月后我可能還是得靠重新踩坑才能想起來。如果你剛開始學shell腳本我的建議很樸素從改造自己昨天手工敲過的命令開始今天把它寫成腳本明天給腳本加參數(shù)和錯誤處理后天再試著用函數(shù)重構一遍。不用特意去找復雜案例你日常的重復勞動就是最好的練習題。一次把一個小的需求做扎實腳本能力就是這么積累起來的。