如何檢測是否已讀取Bash環境變量？

Question

我有一個腳本，通過環境變量提供配置。 由於配置是手動編輯的，因此可能會將從未使用過的拼寫錯誤和變量添加到配置中。

有沒有辦法獲取有關變量的元數據，如果沒有讀取變量，是否允許執行后步驟發出警告？

可接受的答案包括，

• 一種計算var讀取次數的方法
• 如果已讀取var，則為true的標志
• 一種確定訪問var的最后時間的方法

可能存在上面未列出的其他可接受的答案。

出現此問題的部分原因是默認情況下Bash是無類型的。

Answer 1

你的帖子中有兩個問題。 第一個問題：

如何檢測是否已讀取Bash環境變量？

雖然沒有一個可接受的答案包括我的，但我會回答第一個問題以造福他人：

無論如何，除了修改Bash。

你可以自由地拒絕它。

第二個問題：

有沒有辦法獲取有關變量的元數據，如果沒有讀取變量，是否允許執行后步驟發出警告？

提出這個問題沒有多大意義，因為可能的答案不包括在可接受的答案列表中。 但無論如何我會回答它：

不，除非Bash被修改。

現在，即使你可能對我的意見不感興趣，因為它不在可接受的答案列表中，但我還是會將它作為練習呈現給我，也許對其他人來說可能是有用的信息。

首先，在這種情況下發出警告通常是無用的，尤其是在執行之后。 無論在提供參數方面犯了什么錯誤，它們在那個時候已經生效，無論是數據損壞還是時間丟失。 此外，如果他們認為腳本的工作結果沒問題，大多數人都不會注意到警告。 他們可能后來發現他們錯了，但可能為時已晚。

如果您要驗證參數，請在執行前執行此操作，如果錯誤則中止 。

確保環境變量名稱中沒有拼寫錯誤的一種方法是通過要求其名稱以固定字符串為前綴，然后驗證具有該前綴的所有變量名稱是否為程序已知，為它們創建名稱空間。 但是，這不能防止前綴字符串中的拼寫錯誤。 盡管如此，我所知道的其他程序並沒有這樣做，這可能意味着幾乎沒有人期望這樣的行為來自程序。 這違反了“最少驚喜的規則”，而且，我會說，這是不必要的。

我建議根本不驗證環境變量名稱。 如果您的程序具有復雜的配置（需要驗證），請不要將其放入環境中。 將其放入配置文件中，該文件不會與其他程序共享。

一種簡單的方法是使配置文件成為源shell腳本，它設置了一堆變量。 這將允許輕松“解析”（如Bash將這樣做）和驗證。 要驗證它，請在子shell中獲取它（因此主shell不受影響），輸出已設置的變量的名稱，過濾掉在源之前設置的變量，然后將它們與已知配置變量名稱列表進行比較。

像這樣的東西：

function list_vars() {
    declare -p | awk -F'[ =]' '/^declare/ {print $3}'
}

function unset_vars() {
    while read v; do
        unset "$v" 2>/dev/null;
    done < <(list_vars);
}

declare -a CONF_VAR_NAMES=(FOO BAR BAZ)

extra_vars=`
    (
        # Unset all variables that can be unset (and thus set)
        unset_vars
        # List variables set after sourcing configuration
        (. conf_file.sh; list_vars) |
            # Remove variables set before sourcing
            grep -v -F -f <(list_vars)
    ) |
        # Remove known variables
        grep -v -F -f <(IFS=$'\n'; echo "${CONF_VAR_NAMES[*]}")
`

if [ -n "$extra_vars" ]; then
    echo "Unknown variables set by configuration script: $extra_vars" >&2
    exit 1
fi

但是，您可能需要對PATH和其他重要變量進行特殊處理。 在驗證時，在采購之前簡單地將所有變量設置為只讀可能是個好主意。