錯誤代碼:

grep foo | wc -l

正確代碼:

grep -c foo

對於多個文件

錯誤代碼:

grep foo * .log | wc -l

正確代碼:

cat * .log | grep foo -c

修正原因:

這單純是一種程式編碼上風格問題，因 grep 可以直接進行計算無須再次利用管道方式傳送至 wc 進行運算。

檢查有無符合的匹配項目，在沒有符合的項目時(參數值==0)，此情形下使用 grep -q 甚至更加清晰及高效率，例如下列示範:

if grep -q pattern file; then
   echo "此文件有符合的項目"
fi

當如果執行 foo | grep bar | wc -l，在正常情形下無法顯示 grep 執行時的異常訊息，並且始終顯示執行成功，錯誤排除時難以查找問題。如果替換成 foo | grep -c bar 則在沒有匹配項目時退出會顯示 0 。

例外狀況:

如果在特定情形下 wc 指令可以使結果更清楚，就可以忽略此寫法。

參考來源:

• SC2126

錯誤代碼:

echo "Name:\t$value"

正確代碼:

printf 'Name:\t%s\n' "$value"

修正原因:

特殊字元像是 \t 或是 \n 並不會被 echo 轉義成特殊字元，而會如實的列印出字面上的 \t 及 \n。但 printf 會確實的解析此類型的特殊字元，應改變使用習慣。

部分Linux 支援像是使用 echo -e ‘\t’ 和 echo$’\t’。但為了共通性應該避免使用，

printf 確實會擴展這些序列，應改為使用。如果在 VS code 中撰寫shell 腳本開頭宣告#!/bin/sh ， ShellCheck 套件也會發出此警告。

如果您確實需要字面反斜線-t，請使用

echo "\\t"

例外狀況:

無

參考來源:

• SC2028

小編最近在協助公司撰寫設備檢查 Shell Script，使用了工具 VS code 裡面有套件協助檢查編輯或是程式語法錯誤等問題。發現在編輯習慣上會導致的錯誤，也近一步得到修正，順便就把有修正的錯誤做的紀錄，提醒自己變更寫作習慣。

…

SC2004 Shell 計算參數值時無須代入 $ / $ {}閱讀全文 »