爲什麼env變量的名稱中的數字在批處理文件中解釋不正確？

我們有一臺Windows Server 2008 R2機器，它擁有一個目錄，用於保存我們開發團隊使用的所有第三方庫。我設置了一個名爲3P_Libs的系統環境變量。從命令提示符我可以看到正確的值：爲什麼env變量的名稱中的數字在批處理文件中解釋不正確？

D:\_AMG_Integration_\_NightlyBuild_>echo %3P_Libs% 
D:\_third_party_libraries_

我有一個每晚構建腳本建立時引用這條道路，但因爲「3」掉落留下的P_Libs只值它拋出一個錯誤，而不是正確的路徑。我附加值的回聲從腳本：

D:\_AMG_Integration_\_NightlyBuild_>echo P_Libs 
P_Libs

看來，該批處理文件本身作爲第三輸入變量儘管沒有輸入已經提供給腳本的事實解釋％3。有沒有需要做的事情來逃避'3'？

2013-12-09 jterm

在ab atch文件，'％3'表示「第三個命令行參數」。 –

爲什麼不簡單更改$ 3P_libs中的Var名稱，例如？ – SachaDee

我在問題中提到％3是第三個參數。是的，我可以重命名它，但我的問題是這個值可以逃脫，所以我不必更新每個人的引用這個路徑，所以我的腳本將工作？ – jterm

你可以這樣說：

setlocal enableDelayedExpansion 
echo !3P_Libs!

2013-12-09 23:28:11 Myforwik

正如Raymond Chen所指出的，原因是腳本將%3作爲傳遞給它的第三個參數。，在目前來我唯一的辦法解決這個問題是使用延遲擴展或for /f：

setlocal enableDelayedExpansion 
echo !3P_Libs! 
endlocal

FOR/F：

for /f "tokens=2* delims==" %%a in ('set 3P_Libs') do echo %%a

2013-12-09 22:41:45 npocmaka

如果只是被回顯：'set 3P_Libs'將起作用。問題在於'echo'。 'C：\>％3P_Lib％'給出了正確的路徑（當然有錯誤，因爲它的路徑，而不是程序。 – Stephan

回答