試實(shí)戰(zhàn))
1. UEFI Shell到底是什么為什么調(diào)試固件繞不開它先講個親身經(jīng)歷。前兩年幫朋友修一臺進(jìn)不去系統(tǒng)的老機(jī)器開機(jī)黑屏連BIOS Setup都進(jìn)不去風(fēng)扇轉(zhuǎn)、電源燈亮就是沒畫面。折騰半天最后是靠著UEFI Shell進(jìn)去用幾條命令定位到啟動項損壞直接從Shell里把默認(rèn)啟動項拉回來機(jī)器才救活。那時候我就覺得UEFI Shell這玩意兒看著不起眼真到關(guān)鍵時刻比什么PE盤、LiveCD都管用。UEFI Shell是運(yùn)行在UEFI固件環(huán)境下的一個命令行解釋器你可以把它理解成BIOS年代的DOS——系統(tǒng)沒起來之前它先給你一個能操作硬件、讀寫文件、執(zhí)行腳本的入口。它不依賴硬盤上的操作系統(tǒng)只要板子上的UEFI固件能跑起來Shell就能用。很多人分不清UEFI Shell和BIOS Setup的關(guān)系。簡單說BIOS Setup是圖形化或半圖形化的配置界面能改的東西被廠商鎖死了無非是啟動順序、電源管理、虛擬化開關(guān)這些。UEFI Shell則是另一層?xùn)|西它面向的是真正能操作固件和硬件的人——你可以直接訪問EFI系統(tǒng)分區(qū)里的文件可以加載驅(qū)動可以讀寫內(nèi)存和IO端口可以用腳本批量執(zhí)行命令甚至可以操作ACPI表、管理啟動項、刷寫固件。如果你在做固件開發(fā)、主板驗(yàn)證、系統(tǒng)集成或者單純喜歡折騰底層這玩意兒是繞不開的。這篇文章我不會去貼那份幾百頁的UEFI Shell規(guī)范文檔而是按我自己實(shí)際使用的路徑把腳本語法這塊徹底講透變量、參數(shù)、分支循環(huán)、文件操作、外部命令加載再到真實(shí)場景下的完整腳本拆解。最后一部分我會把這幾年前前后后踩過的大坑一并列出來這些才是文檔里查不到的東西。如果你是完全沒接觸過UEFI Shell的新手建議你把前兩節(jié)看完再上手如果你已經(jīng)寫過幾個.nsh腳本可以直接跳到第4和第6節(jié)里面有不少細(xì)節(jié)值得對照。2. 搭建實(shí)操環(huán)境Shell不是所有機(jī)器都自帶2.1 主流板卡上怎么進(jìn)UEFI Shell先解決一個實(shí)際問題Shell從哪來大多數(shù)商業(yè)主板默認(rèn)不預(yù)裝UEFI Shell你得自己想辦法。常見的入口有幾個部分工作站和服務(wù)器主板比如某些品牌的商務(wù)機(jī)型在BIOS Setup里提供一個Launch UEFI Shell的選項打開后重啟就能直接進(jìn)。沒有內(nèi)置Shell的機(jī)器可以把Shell.efi放到FAT32格式的U盤或EFI系統(tǒng)分區(qū)里然后在啟動菜單里選UEFI: U盤名進(jìn)入。前提是U盤根目錄下有EFI/BOOT/BOOTX64.EFI64位x86機(jī)器或者你把Shell.efi命名為這個路徑下的啟動文件。在EDK2開發(fā)環(huán)境里直接用QEMU加OVMF固件跑一個虛擬機(jī)啟動時也能進(jìn)Shell這個方法對學(xué)習(xí)語法來說反而是最省事的。我自己平時調(diào)試用的組合是一臺裝了Linux的筆記本跑QEMUOVMF固件里直接集成Shell配合虛擬的FAT32磁盤鏡像腳本寫完不用燒到真實(shí)板卡就能驗(yàn)證語法。這個方法強(qiáng)烈推薦——因?yàn)檎鏅C(jī)上反復(fù)重啟測試時間成本太高了而且有些機(jī)器進(jìn)Shell的快捷鍵和菜單路徑差異很大會打斷你調(diào)試的思路。2.2 版本差異Shell 2.0與細(xì)節(jié)變化UEFI Shell有兩種主版本Shell 1.0和Shell 2.0。2.0是EDK2默認(rèn)的版本功能強(qiáng)很多比如支持for循環(huán)、支持-b分頁參數(shù)、支持環(huán)境變量的字符串操作等。1.0基本只在內(nèi)嵌的老固件里能碰到。到了2.0之后不同固件版本的具體實(shí)現(xiàn)其實(shí)也有差異。有的廠商自己編譯的Shell會砍掉一些命令有的則集成了一堆EFI Shell下的DXE驅(qū)動。所以在某個機(jī)器上能用的腳本換臺機(jī)器可能就提示命令找不到。這種事兒我遇到過不止一次后面第6節(jié)會專門講怎么排查?，F(xiàn)階段你只需要記住一個原則寫腳本時盡量用最基礎(chǔ)的內(nèi)置命令少依賴廠商自定義的擴(kuò)展命令。2.3 文件系統(tǒng)支持與Shell下的盤符邏輯進(jìn)到Shell之后第一件事通常是敲map命令看當(dāng)前有哪些可用映射。UEFI Shell下沒有C盤D盤的概念它用FS0:、FS1:這樣的格式來表示文件系統(tǒng)BLK0:、BLK1:表示塊設(shè)備。比如Shell map輸出會列出當(dāng)前能訪問的所有設(shè)備映射。你輸入FS0:回車就能切換到第一個文件系統(tǒng)然后ls看目錄結(jié)構(gòu)。這里有個容易懵的地方一個U盤分一個區(qū)是FS0:如果某個磁盤上有多個FAT分區(qū)可能會映射成FS0:、FS1:而且映射順序不一定等于你的物理順序和UEFI固件對設(shè)備的枚舉順序有關(guān)。還有一點(diǎn)Shell只認(rèn)FAT12/16/32格式的文件系統(tǒng)NTFS、ext4這些在純Shell環(huán)境下是不認(rèn)的。你要想從U盤加載腳本U盤必須是FAT32格式別踩這個坑。3. UEFI Shell腳本的母語內(nèi)置命令與幫助體系3.1 先弄清楚Shell的命令從哪里來在動手寫腳本之前得先搞明白Shell命令的分類。UEFI Shell下的命令大致分三類Shell內(nèi)置命令Shell自己實(shí)現(xiàn)的比如cd、ls、cp、mv、rm、set、alias、for、if等。這些不依賴外部文件永遠(yuǎn)可用。EFI應(yīng)用程序編譯出來的.efi文件放在某一路徑下通過Shell去加載執(zhí)行。最典型的就是Shell.efi本身以及你寫的一些.efi小工具。Shell命令腳本.nsh本次重點(diǎn)。本質(zhì)是一個包含若干Shell命令的文本文件Shell逐行解釋執(zhí)行。你在Shell里敲一條命令Shell會先查內(nèi)置命令表然后查當(dāng)前目錄下有沒有對應(yīng)的.efi或.nsh文件再根據(jù)path環(huán)境變量的設(shè)置去一系列目錄里查找。這個查找順序很重要后面會講一個因此引發(fā)的詭異Bug。3.2 常用內(nèi)置命令的功能分組我按使用場景把常用命令分了幾組這比死記命令列表高效得多文件操作類ls、cd、cp、mv、rm、mkdir、touch、type查看文本文件內(nèi)容、edit文本編輯器、hexedit十六進(jìn)制編輯器。其中edit寫短腳本非常實(shí)用不用來回在Shell和操作系統(tǒng)之間切換。系統(tǒng)信息類mem內(nèi)存信息、devices設(shè)備列表、drivers驅(qū)動列表、bcfg啟動項管理、smbiosviewSMBIOS信息、acpiACPI表信息、ver版本信息。內(nèi)存與端口操作類mm內(nèi)存讀寫、io端口讀寫、dmemdump內(nèi)存、dmesg類似Linux的dmesg。這些屬于固件調(diào)試的利器也是Shell最危險的一面——改錯一個內(nèi)存地址系統(tǒng)直接就掛。腳本控制類set、if、for、while、goto、shift、pause、stall延時、exit退出腳本或Shell、reset重啟。這些是腳本語法的核心。Shell環(huán)境類alias命令別名、path可執(zhí)行文件搜索路徑、map設(shè)備映射、echo、cls。其中map命令本身還能用來修改映射關(guān)系。3.3 用好-help參數(shù)比查文檔快十倍UEFI Shell每個命令都支持-?也就是help的縮寫參數(shù)。比如Shell ls -?就會輸出ls的完整用法、參數(shù)說明、示例。這個參數(shù)信息是命令自己內(nèi)置的不需要聯(lián)網(wǎng)查文檔。我寫腳本的日常流程基本上是拿不準(zhǔn)某個參數(shù)就先命令 -?看一遍然后開一個Shell窗口在機(jī)器上驗(yàn)證另一個窗口用edit寫腳本。有一個小細(xì)節(jié)-?和-h不一定等價。部分命令只支持-?你要敲-h反而會被當(dāng)成非法參數(shù)。這個和Linux下的習(xí)慣不一樣很多人上來就敲-h然后提示參數(shù)錯誤還以為命令壞了。4. 腳本語法核心變量、參數(shù)、流程控制寫法到這里開始進(jìn)入正題。UEFI Shell腳本文件是.nsh后綴的純文本文件一行一條命令支持#注釋。我把語法拆成幾個相對獨(dú)立的部分來講。4.1 變量與環(huán)境變量%符號的用法UEFI Shell里所有變量都是環(huán)境變量沒有單獨(dú)的局部變量概念。你用它它就是一個全局的環(huán)境變量你刪它用set命令。設(shè)置和引用的語法set MYVAR hello echo %MYVAR%第一行把環(huán)境變量MYVAR設(shè)成hello第二行輸出hello。注意引用變量時必須用%包裹這和Windows批處理里的%VAR%寫法一樣。刪除變量用set MYVAR后面不跟值就是刪除?；蛘遱et -d MYVAR?？串?dāng)前所有環(huán)境變量直接敲set不帶參數(shù)。有一個必須記住的坑**環(huán)境變量的值里如果包含特殊字符解析順序會導(dǎo)致意想不到的結(jié)果。**Shell對%的解析是在執(zhí)行命令之前做替換所以如果你在腳本里想輸出一個字面上的%得寫兩個%轉(zhuǎn)義——echo %%輸出一個%。這一點(diǎn)和批處理腳本一模一樣。Shell自帶一些內(nèi)置變量經(jīng)常用到的有%path%可執(zhí)行文件搜索路徑多個目錄用分號分隔。%cwd%當(dāng)前工作目錄。%lasterror%上一條命令的返回值/錯誤碼。%startup%是否以startup.nsh方式啟動腳本里可以用它判斷當(dāng)前是不是開機(jī)自啟。我實(shí)際寫腳本用到%lasterror%的頻率非常高。因?yàn)槟_本本身沒有try-catch機(jī)制判斷命令是否執(zhí)行成功唯一的辦法就是檢查錯誤碼。4.2 腳本參數(shù)與shift處理執(zhí)行一個.nsh腳本時可以帶參數(shù)比如Shell test.nsh arg1 arg2在腳本內(nèi)部%0拿到的是腳本名自身%1到%9依次是參數(shù)1到參數(shù)9%*是全部參數(shù)從參數(shù)1開始。有一個比較坑的地方UEFI Shell雖然支持shift命令但它的shift不太好用——它是把參數(shù)整體左移一位%1變成原來的%2以此類推。如果你拿%1做循環(huán)取出所有參數(shù)寫到第三四個參數(shù)之后容易亂套。我自己寫腳本處理不定長參數(shù)時通常直接繞開%1~%9改用%*配合字符串截取操作。字符串操作指令在UEFI Shell里是%VAR:~start,len%這種風(fēng)格比如set fullarg %* set firsttwo %fullarg:~0,2%這可以截取參數(shù)的前兩個字符。語法風(fēng)格接近Windows批處理的%VAR:~m,n%。但因?yàn)镾hell對%的解析比較嚴(yán)格這種寫法在嵌套環(huán)境里偶爾會出問題。所以遇到特別復(fù)雜的字符串處理我更推薦在腳本里調(diào)用echo加重定向生成一個新的臨時腳本再執(zhí)行這個臨時腳本——雖然笨但可控。4.3 分支if/then/else/endifUEFI Shell的if語法支持三種基礎(chǔ)形式if 條件 then 命令 endifif 條件 then 命令 else 命令 endifif 條件 then 命令 elseif 條件 then 命令 endif條件判定的寫法分兩種。一種是判斷環(huán)境變量是否存在或等于某個值if %MYVAR% hello then echo match endif另一種是文件存在性判斷if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo found bootloader endif注意兩邊我習(xí)慣都加引號這是從批處理時代養(yǎng)成的習(xí)慣——如果%MYVAR%是空值不加引號會導(dǎo)致整個條件表達(dá)式語法不完整腳本會報錯。加了引號之后空值就變成了一個空字符串參與比較穩(wěn)妥很多。還有三個邏輯運(yùn)算符可以用AND、OR、NOT。比如if exist FS0:\flag.txt AND %mode% test then echo enter test mode endif4.4 循環(huán)for和whilefor循環(huán)的語法是for %i in (val1 val2 val3) echo %i endfor注意循環(huán)變量用單個%不是雙%for %i in (1 2 3 4) echo %i endfor如果想遍歷文件列表可以這么寫for %i in FS0:\*.nsh echo %i endforShell會自己展開通配符把匹配到的文件路徑依次賦給%i。while循環(huán)的語法也類似while 條件 命令 endwhile這里有一個重要限制UEFI Shell的循環(huán)沒有計數(shù)器自動遞增的能力如果你要用while計數(shù)必須自己修改變量。set counter 0 while %counter% 5 echo count is %counter% set counter %counter%1 endwhile等一下UEFI Shell的set命令不支持算術(shù)運(yùn)算。set counter %counter%1的結(jié)果是字符串01不是數(shù)字1。這是Shell腳本最讓人抓狂的地方——它沒有內(nèi)置的整數(shù)運(yùn)算能力。那怎么實(shí)現(xiàn)計數(shù)兩個辦法。一是借助for %i in (1 2 3 4 5)這種顯式列表實(shí)現(xiàn)固定次數(shù)循環(huán)二是用外部工具比如edk2自帶的parse命令或者其他小工具去處理數(shù)值。或者退一步循環(huán)次數(shù)已知就用for循環(huán)條件是基于環(huán)境變量且不需要自增的情況才用while。這個思路能讓你的腳本少走很多彎路。4.5 傳說中的goto和標(biāo)簽UEFI Shell支持goto跳轉(zhuǎn)和標(biāo)簽goto :start ... :start echo start here標(biāo)簽是冒號加名字goto語句跳轉(zhuǎn)到指定標(biāo)簽。注意goto不能跳出當(dāng)前腳本文件的邊界——你沒法在一個.nsh里goto到另一個.nsh的標(biāo)簽。這和批處理一樣。但goto在Shell里還有一個比較危險的行為如果標(biāo)簽不存在Shell不會報錯退出而是直接跳到腳本末尾然后返回一個%lasterror%錯誤碼。如果腳本是開機(jī)自啟動的startup.nsh這種靜默失敗很容易被忽略后面真正要用的操作沒執(zhí)行你還不明所以。4.6 把多個命令串起來重定向和管道UEFI Shell支持重定向是覆蓋寫是追加寫。比如把命令輸出保存到文件ls FS0:\filelist.txt smbiosview -b FS0:\smbios.txt管道|在UEFI Shell里的支持比我想象中弱一些。實(shí)測下來管道在某些版本的Shell里能工作在另一些版本里會直接報語法錯誤。比如ls | grep .efi這個命令在部分EDK2版本里能用Shell內(nèi)置了grep的簡易實(shí)現(xiàn)但換到另一塊主板上可能就失敗了。我的經(jīng)驗(yàn)是正式腳本里盡量少用管道需要過濾輸出就先把結(jié)果重定向到臨時文件再用search命令或type加parse去處理。寧可多寫兩行也不要在管道這個特性上賭固件實(shí)現(xiàn)。5. 一個能直接上機(jī)跑的診斷備份腳本逐步拆解語法講再多不如一個完整的例子。下面這個腳本是我在某次批量主板測試中實(shí)際用的一個簡化版本功能包括檢查設(shè)備映射、備份當(dāng)前BIOS區(qū)域模擬、收集SMBIOS信息、檢查關(guān)鍵啟動文件是否存在。5.1 腳本的目標(biāo)與運(yùn)行邏輯這個腳本解決一個很實(shí)際的問題現(xiàn)場運(yùn)維人員拿U盤插到機(jī)器上跑一下自動把診斷信息和備份文件落盤然后退出。不需要他們懂Shell命令不需要手動敲一堆指令。腳本放在U盤根目錄啟動進(jìn)入Shell后執(zhí)行FS0:\debug.nsh所有輸出寫到同一個日志目錄下。5.2 完整腳本內(nèi)容# debug.nsh - 簡易固件診斷與備份腳本 # 用法: debug.nsh [日志目錄] set LOGDIR %1 if %LOGDIR% then set LOGDIR FS0:\LOGS endif if not exist %LOGDIR% then mkdir %LOGDIR% endif set LOGFILE %LOGDIR%\debug_%lasterror%.log # 1. dump設(shè)備映射 echo %LOGFILE% echo Device Map %LOGFILE% map %LOGFILE% # 2. dump SMBIOS信息 echo %LOGFILE% echo SMBIOS Info %LOGFILE% smbiosview -b %LOGFILE% # 3. 檢查關(guān)鍵EFI啟動文件 echo %LOGFILE% echo Check BootLoaders %LOGFILE% set FOUND 0 if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo FS0: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif if exist FS1:\EFI\BOOT\BOOTX64.EFI then echo FS1: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif # 4. dump啟動項 echo %LOGFILE% echo Boot Option List %LOGFILE% bcfg boot dump %LOGFILE% # 5. 備份當(dāng)前啟動項配置 echo %LOGFILE% echo Boot Option Backup %LOGFILE% bcfg boot dump -v %LOGFILE% echo %LOGFILE% echo Done. Log saved to %LOGFILE% pause exit5.3 逐段講解為什么這樣寫參數(shù)與默認(rèn)值腳本開頭先取%1作為日志目錄如果沒傳參就默認(rèn)用FS0:\LOGS。這里用到了前面講過的空判斷技巧——if %LOGDIR% 空值時%LOGDIR%被替換成空字符串表達(dá)式就變成了if 成立進(jìn)入默認(rèn)賦值邏輯。日志文件的命名我在這里耍了個小聰明debug_%lasterror%.log。第一次執(zhí)行時%lasterror%可能為空或0第二次執(zhí)行時它等于上一次某個命令的返回值。這個命名其實(shí)不夠嚴(yán)謹(jǐn)最終生成的文件名可能不唯一但勝在簡單。嚴(yán)格一點(diǎn)的做法是用%time%或%date%拼一個時間戳但UEFI Shell里的時間格式依賴固件實(shí)現(xiàn)輸出經(jīng)常是10:20:30帶冒號Windows文件系統(tǒng)不認(rèn)冒號所以用時間戳反而容易踩坑。smbiosview -b參數(shù)smbiosview是EDK2自帶的SMBIOS查看命令-b表示分頁輸出。在重定向到文件時分頁參數(shù)不僅不會打斷輸出反而能讓內(nèi)容一次性完整落盤不會因?yàn)榭刂婆_緩沖區(qū)限制丟行。這個細(xì)節(jié)最開始我不知道導(dǎo)致dump出來的SMBIOS信息只有前幾行排查了半天。bcfg boot dumpbcfg是啟動項管理命令。bcfg boot dump列出當(dāng)前所有啟動項-v參數(shù)會輸出更詳細(xì)的信息比如關(guān)聯(lián)的設(shè)備路徑。這個命令對排查為什么開不了機(jī)類問題非常有用。注意bcfg在某些精簡固件里可能沒被編譯進(jìn)去如果提示命令不存在回頭看我第6節(jié)的排查方法。5.4 執(zhí)行與驗(yàn)證這個腳本寫完后實(shí)際執(zhí)行時我用了一個小技巧先在QEMU里跑一遍確認(rèn)語法沒問題再放到真實(shí)U盤上跑。QEMU里跑的時候第一次執(zhí)行會報一堆smbiosview: command not found之類的錯誤嗎其實(shí)不會因?yàn)镺VMF固件里帶了SHELL的完整命令集。但真機(jī)上確實(shí)可能缺命令所以我在腳本里做了一件事所有可能失敗的命令后面都靠%lasterror%去判斷。更關(guān)鍵的一點(diǎn)寫腳本時每條命令的返回值都是獨(dú)立的。比如mkdir %LOGDIR%在目錄已存在時會返回錯誤碼但這不影響腳本繼續(xù)執(zhí)行——Shell腳本默認(rèn)不會因?yàn)閱螚l命令失敗而中止除非你顯式寫-exit或使用abort命令。這也是很多新手感到困惑的地方明明上一行報錯腳本還是往下跑了。理解這一點(diǎn)就能明白為什么腳本里要手動檢查關(guān)鍵步驟的%lasterror%。6. 踩坑實(shí)錄六年UEFI Shell使用中遇到的典型問題這一部分單獨(dú)拎出來因?yàn)檫@些坑我?guī)缀醵紝?shí)實(shí)在在踩過每一類都花過不少時間排查。寫出來幫你省點(diǎn)時間。6.1 文件系統(tǒng)大小寫與路徑分隔符UEFI Shell的文件系統(tǒng)和UEFI規(guī)范一樣不區(qū)分大小寫但輸出時可能混合大小寫。有次我寫了一個判斷if exist fs0:\EFI\BOOT\BOOTX64.EFI then注意我寫的是小寫fs0。Shell能認(rèn)出這個盤符嗎在大多數(shù)固件實(shí)現(xiàn)里可以但有些嚴(yán)謹(jǐn)?shù)膶?shí)現(xiàn)可能要求必須用FS0:全部大寫。我的建議是腳本里統(tǒng)一用大寫盤符、大寫路徑分隔符避免在固件兼容性上賭運(yùn)氣。路徑分隔符一律用反斜杠\不要用正斜杠/。UEFI規(guī)范里正斜杠在某些上下文里有特殊含義比如作為參數(shù)前綴萬一你把路徑寫錯排查起來非常痛苦。6.2 命令找不到環(huán)境變量和當(dāng)前目錄的坑path環(huán)境變量影響Shell對可執(zhí)行文件的查找范圍。有次我腳本里用了一個自研的診斷.efi工具放在U盤的EFI\Tools目錄下。腳本第一行執(zhí)行set path FS0:\EFI\Tools;%path%結(jié)果下一行調(diào)用這個工具時Shell提示命令找不到。排查了半天發(fā)現(xiàn)是set path這個操作本身的問題——當(dāng)一個環(huán)境變量名是path時Shell在執(zhí)行set path ...之后當(dāng)前這條命令的解析還沒結(jié)束它用的還是舊的path。等到下一條命令時新的path才生效。這看起來很正常但問題在于腳本第一行設(shè)置path第二行就要用應(yīng)該沒問題啊后來發(fā)現(xiàn)真正的原因是UEFI Shell在解析腳本時某些實(shí)現(xiàn)會在每行執(zhí)行前重新讀取path變量而另一些實(shí)現(xiàn)只在腳本開始執(zhí)行時讀取一次path快照。第一種實(shí)現(xiàn)里你中途改path對后續(xù)行生效第二種實(shí)現(xiàn)里你必須把path設(shè)置放在腳本最開頭或者用一個外層的wrapper腳本去設(shè)置path再調(diào)用真正的腳本。 這個行為差異沒有寫在規(guī)范里純靠實(shí)測發(fā)現(xiàn)。現(xiàn)在的處理策略是把path設(shè)置獨(dú)立放在一個env.nsh文件里所有需要環(huán)境變量的腳本第一行都改成include env.nsh或直接復(fù)制那兩行set命令。繞開實(shí)現(xiàn)差異。6.3include指令別對它寄予太多希望UEFI Shell有一個include命令可以理解為類似C語言的#include。用法include FS0:\env.nsh但實(shí)測下來include在多個版本里行為不太穩(wěn)定有的要求被include的文件必須帶.nsh擴(kuò)展名否則拒絕執(zhí)行有的在相對路徑下解析失敗。而且它不能傳參數(shù)被include的腳本里%1~%9會被清空還是保留原調(diào)用者的參數(shù)不同版本表現(xiàn)不一樣。我后來基本不用include需要復(fù)用代碼就直接把內(nèi)容復(fù)制進(jìn)主腳本或者通過執(zhí)行子腳本的方式傳遞參數(shù)call FS0:\subtask.nsh %parm%call是執(zhí)行另一個腳本的正確姿勢它會等子腳本執(zhí)行完再回到當(dāng)前腳本繼續(xù)。雖然每啟動一次子腳本有開銷但在腳本規(guī)模不大的前提下可維護(hù)性比include強(qiáng)太多。6.4 腳本編碼與不可見字符UEFI Shell腳本文本文件的編碼要求不算嚴(yán)格但必須注意兩點(diǎn)。第一**保存為Unix換行LF還是Windows換行CRLF**實(shí)測而言Shell對兩種換行都能處理但混合換行會出問題。如果腳本在Windows下編輯完放到Linux環(huán)境改了一行再拷回U盤文件中同時出現(xiàn)LF和CRLFShell會在某些版本里把一個\r當(dāng)成命令的一部分導(dǎo)致命令不存在之類的報錯而且報錯指向的行和你實(shí)際出錯的行對不上——因?yàn)橹鹦薪馕鰰rCR被吞掉與否取決于實(shí)現(xiàn)。第二如果腳本里含非ASCII字符比如中文注釋必須在文件頭部加BOM否則Shell的文本解析可能亂碼。這個問題在UEFI Shell 2.0之后有所緩解但保險起見腳本里我一般只用純英文注釋。6.5%lasterror%的時效性%lasterror%變量在每條命令執(zhí)行后都會更新但它有個特點(diǎn)內(nèi)置變量對set命令本身也會被更新。也就是說你執(zhí)行set foo 1之后%lasterror%變成的是這次set是否成功的狀態(tài)而不是最初那條你想檢查的命令的狀態(tài)。所以正確的檢查姿勢是這樣的bcfg boot dump FS0:\boot.txt set ERRCODE %lasterror% if %ERRCODE% 0 then echo dump ok else echo dump failed with %ERRCODE% endif先把%lasterror%存到一個普通環(huán)境變量里再拿去判斷。直接寫if %lasterror% 0雖然也能用但中間一旦插入別的命令比如echo值可能已經(jīng)變了。還有一個小細(xì)節(jié)%lasterror%雖說是錯誤碼但Shell命令成功時的返回值不一定是0。有些命令返回的不是標(biāo)準(zhǔn)0而是自定義狀態(tài)碼。所以判斷成功時更可靠的方式是檢查輸出文件的內(nèi)容是不是符合預(yù)期而不是只看返回碼。6.6 內(nèi)存讀寫命令的危險性mm命令可以在Shell里直接讀寫物理內(nèi)存和IO端口Shell mm 0xE0000000 # 讀這個地址的內(nèi)容 Shell mm 0xE0000000 0x1F # 往這個地址寫0x1F這是固件調(diào)試的利器但也是最大的危險源。寫錯一個地址輕則系統(tǒng)死機(jī)重則把SPI Flash里的固件搞壞。我見過同事在調(diào)試時用mm往某個不知道是什么的地址寫了個值重啟后板子直接起不來最后靠編程器重新燒固件才救回來。在腳本里涉及mm操作我的建議是先dmem或mem把目標(biāo)區(qū)域讀一遍確認(rèn)地址有效。寫操作前人工確認(rèn)三次地址沒錯。不要在自動化腳本里放未驗(yàn)證的mm寫操作。操作完馬上reset重啟觀察不要繼續(xù)跑后面的腳本。6.7startup.nsh的自動執(zhí)行機(jī)制如果你把U盤插上Shell啟動時會自動嘗試執(zhí)行U盤根目錄下的startup.nsh。這是一個很方便的機(jī)制但也容易出事故。有一次我調(diào)試腳本把startup.nsh放到U盤根目錄內(nèi)容是一個死循環(huán)等待某個條件。結(jié)果每次開機(jī)進(jìn)Shell就卡死拔U盤都來不及——因?yàn)镾hell啟動時讀不到文件系統(tǒng)U盤被占住拔掉就報錯。最后只能重啟進(jìn)BIOS把啟動順序改成直接進(jìn)系統(tǒng)再把U盤格式化才解決。所以我對startup.nsh的態(tài)度是開發(fā)階段不要把調(diào)試腳本命名為startup.nsh用普通文件名手動執(zhí)行。需要自動執(zhí)行時startup.nsh里只放一個調(diào)用其他腳本的語句不要寫長邏輯。重要操作前先pause給你自己留一個取消執(zhí)行的機(jī)會。6.8 腳本超時與交互Shell腳本執(zhí)行過程中如果需要人工輸入通常用pause命令等按任意鍵。但pause在無人值守場景下會卡住整個流程。如果需要倒計時自動繼續(xù)可以寫一個循環(huán)配合stall命令單位是微秒實(shí)現(xiàn)延時set countdown 5 while %countdown% 0 echo Continue in %countdown% ... stall 1000000 set countdown ... endwhile這里有個矛盾set不支持算術(shù)運(yùn)算所以set countdown %countdown%-1是無效的。實(shí)際做法是把倒計時變量拆成多個if判斷或者干脆用固定次數(shù)的for循環(huán)。比如for %i in (5 4 3 2 1) echo Continue in %i ... stall 1000000 endfor這個方案最簡單既不依賴算術(shù)運(yùn)算也不容易出錯。7. 把Shell腳本用在自動化測試?yán)锏墓こ袒悸纷詈笠徊糠至牧脑趺窗?nsh腳本寫得像工程代碼而不是隨手寫的玩具。這幾年我在固件驗(yàn)證項目里逐漸摸索出一套自己的規(guī)范分享出來供參考。7.1 約定目錄結(jié)構(gòu)一個完整的U盤工具包目錄結(jié)構(gòu)建議如下FS0:\ ├── startup.nsh # 入口腳本可選 ├── scripts\ │ ├── common.nsh # 公共函數(shù)用call調(diào)用 │ ├── debug.nsh │ ├── backup.nsh │ └── flash.nsh ├── tools\ │ ├── shell.efi # 備用Shell │ ├── xxxdiag.efi # 自定義診斷工具 │ └── ... └── logs\ # 日志輸出目錄腳本里統(tǒng)一用scripts\和tools\的絕對路徑不要在幾十行里到處寫FS0:\這種硬編碼。如果U盤盤符變了比如插到不同USB口變成FS1:至少還有救——你只需要改頂部的幾個set變量。7.2 輸出規(guī)范與日志級別UEFI Shell的echo命令沒有彩色輸出也沒法區(qū)分日志級別。我的做法是在腳本里統(tǒng)一一個日志函數(shù)的概念用子腳本實(shí)現(xiàn):log_info echo [INFO] %1 %LOGFILE% goto :EOF但前面說過goto :EOF在UEFI Shell里的支持不完全可靠所以這種函數(shù)寫法我很少用。更實(shí)際的做法是每條輸出都同時打到屏幕和日志文件屏幕輸出幫助操作者實(shí)時了解進(jìn)展日志文件用于事后審計。具體寫法是這樣echo Step 1: dump smbios... | tee %LOGFILE%等等tee命令在UEFI Shell里通常沒有。所以實(shí)際做法是寫兩行echo Step 1: dump smbios... %LOGFILE% echo Step 1: dump smbios...麻煩是麻煩一點(diǎn)但可靠。我已經(jīng)不指望Shell腳本能寫出多優(yōu)雅的日志框架了能穩(wěn)定執(zhí)行比什么都強(qiáng)。7.3 與UEFI固件內(nèi)部的交互變量命名空間環(huán)境變量名不要起得太通用。比如你腳本里用了一個set boot后面某段代碼也用了set boot互相覆蓋了排查起來非常費(fèi)勁。我建議所有腳本變量統(tǒng)一加前綴比如項目名縮寫set DBG_LOGDIR FS0:\LOGS set DBG_MODE 1這樣不同腳本之間的變量沖突概率大大降低。另外注意UEFI Shell的環(huán)境變量會隨腳本退出而保留除非你顯式刪除或整個Shell重啟。也就是說一個腳本設(shè)置的變量另一個腳本能看到。這既是便利也是隱患——一個寫壞了的變量可能在半小時后的另一個腳本里莫名出現(xiàn)。7.4 錯誤碼傳遞與失敗處理腳本失敗時的退出碼是%lasterror%。在自動化測試框架里我們經(jīng)常在Shell腳本的最外層套一個Linux或Windows側(cè)的驅(qū)動腳本用串口或網(wǎng)絡(luò)和Shell交互。Shell側(cè)接收參數(shù)、執(zhí)行測試、返回錯誤碼宿主側(cè)解析。這種模式下exit %lasterror%就非常關(guān)鍵確保Shell退出時把最后的錯誤碼帶出去。但有兩點(diǎn)要特別小心不是所有版本的Shell都支持exit %lasterror%的語法。部分實(shí)現(xiàn)只支持exit不帶參數(shù)返回碼永遠(yuǎn)是0。如果你在.nsh里執(zhí)行了另一個.efi程序該程序的退出碼會通過%lasterror%暴露出來但前提是Shell沒在這之間執(zhí)行其他命令。任何一條命令都可能覆蓋它。為了確保錯誤碼正確傳遞在測試框架里我會專門寫一個report.nshset TEST_RESULT %lasterror% if %TEST_RESULT% 0 then echo PASS FS0:\logs\result.txt else echo FAIL:%TEST_RESULT% FS0:\logs\result.txt endif exit %TEST_RESULT%宿主側(cè)的腳本只認(rèn)result.txt里的內(nèi)容不依賴Shell退出碼——因?yàn)閷?shí)測下來有的固件版本退出碼頭幾位的字節(jié)會被截斷導(dǎo)致宿主側(cè)收到奇怪的值。7.5 與DXE驅(qū)動和EFI應(yīng)用的配合UEFI Shell最有意思的地方是可以加載DXE驅(qū)動和運(yùn)行各種EFI應(yīng)用。比如在測試過程中你可能需要先加載一個自定義的協(xié)議驅(qū)動再跑測試工具。典型寫法load FS0:\tools\MyDriver.efi if %lasterror% 0 then echo driver loaded else echo driver load failed endifload命令加載驅(qū)動后驅(qū)動常駐內(nèi)存。此時可以用drivers命令查看驅(qū)動列表用devices查看設(shè)備節(jié)點(diǎn)。如果有新設(shè)備出現(xiàn)說明驅(qū)動生效了。加載驅(qū)動時特別需要注意驅(qū)動一旦加載成功直到系統(tǒng)重啟前都不會被卸載。你連續(xù)加載同一驅(qū)動兩次第二次會返回錯誤但這個錯誤并不影響第一次加載的效果。所以腳本里不要因?yàn)槟炒渭虞d報錯就判定驅(qū)動有問題要結(jié)合drivers輸出確認(rèn)是否已在列表里。7.6 QEMU聯(lián)調(diào)不燒板子練腳本最后安利一下QEMU調(diào)試法。EDK2項目官方就提供OVMF固件配合QEMU可以完整模擬UEFI環(huán)境。具體步驟下載編譯好的OVMF.fd固件或者自己從EDK2源碼編譯。準(zhǔn)備一個FAT32格式的磁盤鏡像把寫好的.nsh文件放進(jìn)去。啟動命令大致是qemu-system-x86_64 -drive ifpflash,formatraw,fileOVMF.fd -drive formatraw,filefat:rw:./diskQEMU啟動時會自動進(jìn)入OVMF的菜單選擇UEFI Shell即可。這個方法有兩個好處一是完全不用碰真實(shí)硬件腳本寫錯了重啟一下虛擬機(jī)就行二是QEMU支持GDB調(diào)試你可以結(jié)合EDK2源碼單步跟蹤Shell命令的執(zhí)行流程理解每一條命令背后的邏輯。不過對大多數(shù)應(yīng)用場景來說能快速驗(yàn)證語法就夠了也不必深入到那個程度。8. 最后分享幾個關(guān)于Shell腳本的心得回想這幾年跟UEFI Shell打交道的經(jīng)歷最深的感觸是這工具看著像Linux終端用起來像DOS批處理但它的很多細(xì)節(jié)都夾在固件實(shí)現(xiàn)和硬件平臺的縫隙里。同一個腳本在這塊板子上跑得好好的換一塊板子可能就行為迥異。所以我的建議一直沒變——腳本要向最基礎(chǔ)的命令看齊不要賭固件實(shí)現(xiàn)的一致性和文檔沒有覆蓋的邊界行為。具體到日常使用有幾件事是我每次上手都會做的拿到一臺新機(jī)器先敲ver看Shell版本再敲map看設(shè)備最后ls -?、bcfg -?看命令支持情況。花五分鐘快速評估這臺機(jī)器的Shell能力邊界比后面盲寫腳本踩坑強(qiáng)得多。寫任何涉及硬件操作的腳本前先在虛擬機(jī)里跑通邏輯再在真機(jī)上人工跑一遍驗(yàn)證命令可用性和輸出格式最后才正式使用。遇到詭異問題先用type或hexedit看腳本文本有沒有不可見字符然后再懷疑語法。這個排查路徑能解決相當(dāng)一部分奇怪的問題。如果你平時做BIOS開發(fā)或固件測試UEFI Shell腳本看著不起眼但熟練之后真的能幫你把很多重復(fù)的調(diào)試工作變成一條命令的事。把這篇文章里的語法和踩坑點(diǎn)消化掉你大概率就能寫出屬于自己的第一版可復(fù)用腳本了。 UEFI Shell腳本語法詳解：從入門到固件調(diào)試實(shí)戰(zhàn)
1. UEFI Shell到底是什么為什么調(diào)試固件繞不開它先講個親身經(jīng)歷。前兩年幫朋友修一臺進(jìn)不去系統(tǒng)的老機(jī)器開機(jī)黑屏連BIOS Setup都進(jìn)不去風(fēng)扇轉(zhuǎn)、電源燈亮就是沒畫面。折騰半天最后是靠著UEFI Shell進(jìn)去用幾條命令定位到啟動項損壞直接從Shell里把默認(rèn)啟動項拉回來機(jī)器才救活。那時候我就覺得UEFI Shell這玩意兒看著不起眼真到關(guān)鍵時刻比什么PE盤、LiveCD都管用。UEFI Shell是運(yùn)行在UEFI固件環(huán)境下的一個命令行解釋器你可以把它理解成BIOS年代的DOS——系統(tǒng)沒起來之前它先給你一個能操作硬件、讀寫文件、執(zhí)行腳本的入口。它不依賴硬盤上的操作系統(tǒng)只要板子上的UEFI固件能跑起來Shell就能用。很多人分不清UEFI Shell和BIOS Setup的關(guān)系。簡單說BIOS Setup是圖形化或半圖形化的配置界面能改的東西被廠商鎖死了無非是啟動順序、電源管理、虛擬化開關(guān)這些。UEFI Shell則是另一層?xùn)|西它面向的是真正能操作固件和硬件的人——你可以直接訪問EFI系統(tǒng)分區(qū)里的文件可以加載驅(qū)動可以讀寫內(nèi)存和IO端口可以用腳本批量執(zhí)行命令甚至可以操作ACPI表、管理啟動項、刷寫固件。如果你在做固件開發(fā)、主板驗(yàn)證、系統(tǒng)集成或者單純喜歡折騰底層這玩意兒是繞不開的。這篇文章我不會去貼那份幾百頁的UEFI Shell規(guī)范文檔而是按我自己實(shí)際使用的路徑把腳本語法這塊徹底講透變量、參數(shù)、分支循環(huán)、文件操作、外部命令加載再到真實(shí)場景下的完整腳本拆解。最后一部分我會把這幾年前前后后踩過的大坑一并列出來這些才是文檔里查不到的東西。如果你是完全沒接觸過UEFI Shell的新手建議你把前兩節(jié)看完再上手如果你已經(jīng)寫過幾個.nsh腳本可以直接跳到第4和第6節(jié)里面有不少細(xì)節(jié)值得對照。2. 搭建實(shí)操環(huán)境Shell不是所有機(jī)器都自帶2.1 主流板卡上怎么進(jìn)UEFI Shell先解決一個實(shí)際問題Shell從哪來大多數(shù)商業(yè)主板默認(rèn)不預(yù)裝UEFI Shell你得自己想辦法。常見的入口有幾個部分工作站和服務(wù)器主板比如某些品牌的商務(wù)機(jī)型在BIOS Setup里提供一個Launch UEFI Shell的選項打開后重啟就能直接進(jìn)。沒有內(nèi)置Shell的機(jī)器可以把Shell.efi放到FAT32格式的U盤或EFI系統(tǒng)分區(qū)里然后在啟動菜單里選UEFI: U盤名進(jìn)入。前提是U盤根目錄下有EFI/BOOT/BOOTX64.EFI64位x86機(jī)器或者你把Shell.efi命名為這個路徑下的啟動文件。在EDK2開發(fā)環(huán)境里直接用QEMU加OVMF固件跑一個虛擬機(jī)啟動時也能進(jìn)Shell這個方法對學(xué)習(xí)語法來說反而是最省事的。我自己平時調(diào)試用的組合是一臺裝了Linux的筆記本跑QEMUOVMF固件里直接集成Shell配合虛擬的FAT32磁盤鏡像腳本寫完不用燒到真實(shí)板卡就能驗(yàn)證語法。這個方法強(qiáng)烈推薦——因?yàn)檎鏅C(jī)上反復(fù)重啟測試時間成本太高了而且有些機(jī)器進(jìn)Shell的快捷鍵和菜單路徑差異很大會打斷你調(diào)試的思路。2.2 版本差異Shell 2.0與細(xì)節(jié)變化UEFI Shell有兩種主版本Shell 1.0和Shell 2.0。2.0是EDK2默認(rèn)的版本功能強(qiáng)很多比如支持for循環(huán)、支持-b分頁參數(shù)、支持環(huán)境變量的字符串操作等。1.0基本只在內(nèi)嵌的老固件里能碰到。到了2.0之后不同固件版本的具體實(shí)現(xiàn)其實(shí)也有差異。有的廠商自己編譯的Shell會砍掉一些命令有的則集成了一堆EFI Shell下的DXE驅(qū)動。所以在某個機(jī)器上能用的腳本換臺機(jī)器可能就提示命令找不到。這種事兒我遇到過不止一次后面第6節(jié)會專門講怎么排查?，F(xiàn)階段你只需要記住一個原則寫腳本時盡量用最基礎(chǔ)的內(nèi)置命令少依賴廠商自定義的擴(kuò)展命令。2.3 文件系統(tǒng)支持與Shell下的盤符邏輯進(jìn)到Shell之后第一件事通常是敲map命令看當(dāng)前有哪些可用映射。UEFI Shell下沒有C盤D盤的概念它用FS0:、FS1:這樣的格式來表示文件系統(tǒng)BLK0:、BLK1:表示塊設(shè)備。比如Shell map輸出會列出當(dāng)前能訪問的所有設(shè)備映射。你輸入FS0:回車就能切換到第一個文件系統(tǒng)然后ls看目錄結(jié)構(gòu)。這里有個容易懵的地方一個U盤分一個區(qū)是FS0:如果某個磁盤上有多個FAT分區(qū)可能會映射成FS0:、FS1:而且映射順序不一定等于你的物理順序和UEFI固件對設(shè)備的枚舉順序有關(guān)。還有一點(diǎn)Shell只認(rèn)FAT12/16/32格式的文件系統(tǒng)NTFS、ext4這些在純Shell環(huán)境下是不認(rèn)的。你要想從U盤加載腳本U盤必須是FAT32格式別踩這個坑。3. UEFI Shell腳本的母語內(nèi)置命令與幫助體系3.1 先弄清楚Shell的命令從哪里來在動手寫腳本之前得先搞明白Shell命令的分類。UEFI Shell下的命令大致分三類Shell內(nèi)置命令Shell自己實(shí)現(xiàn)的比如cd、ls、cp、mv、rm、set、alias、for、if等。這些不依賴外部文件永遠(yuǎn)可用。EFI應(yīng)用程序編譯出來的.efi文件放在某一路徑下通過Shell去加載執(zhí)行。最典型的就是Shell.efi本身以及你寫的一些.efi小工具。Shell命令腳本.nsh本次重點(diǎn)。本質(zhì)是一個包含若干Shell命令的文本文件Shell逐行解釋執(zhí)行。你在Shell里敲一條命令Shell會先查內(nèi)置命令表然后查當(dāng)前目錄下有沒有對應(yīng)的.efi或.nsh文件再根據(jù)path環(huán)境變量的設(shè)置去一系列目錄里查找。這個查找順序很重要后面會講一個因此引發(fā)的詭異Bug。3.2 常用內(nèi)置命令的功能分組我按使用場景把常用命令分了幾組這比死記命令列表高效得多文件操作類ls、cd、cp、mv、rm、mkdir、touch、type查看文本文件內(nèi)容、edit文本編輯器、hexedit十六進(jìn)制編輯器。其中edit寫短腳本非常實(shí)用不用來回在Shell和操作系統(tǒng)之間切換。系統(tǒng)信息類mem內(nèi)存信息、devices設(shè)備列表、drivers驅(qū)動列表、bcfg啟動項管理、smbiosviewSMBIOS信息、acpiACPI表信息、ver版本信息。內(nèi)存與端口操作類mm內(nèi)存讀寫、io端口讀寫、dmemdump內(nèi)存、dmesg類似Linux的dmesg。這些屬于固件調(diào)試的利器也是Shell最危險的一面——改錯一個內(nèi)存地址系統(tǒng)直接就掛。腳本控制類set、if、for、while、goto、shift、pause、stall延時、exit退出腳本或Shell、reset重啟。這些是腳本語法的核心。Shell環(huán)境類alias命令別名、path可執(zhí)行文件搜索路徑、map設(shè)備映射、echo、cls。其中map命令本身還能用來修改映射關(guān)系。3.3 用好-help參數(shù)比查文檔快十倍UEFI Shell每個命令都支持-?也就是help的縮寫參數(shù)。比如Shell ls -?就會輸出ls的完整用法、參數(shù)說明、示例。這個參數(shù)信息是命令自己內(nèi)置的不需要聯(lián)網(wǎng)查文檔。我寫腳本的日常流程基本上是拿不準(zhǔn)某個參數(shù)就先命令 -?看一遍然后開一個Shell窗口在機(jī)器上驗(yàn)證另一個窗口用edit寫腳本。有一個小細(xì)節(jié)-?和-h不一定等價。部分命令只支持-?你要敲-h反而會被當(dāng)成非法參數(shù)。這個和Linux下的習(xí)慣不一樣很多人上來就敲-h然后提示參數(shù)錯誤還以為命令壞了。4. 腳本語法核心變量、參數(shù)、流程控制寫法到這里開始進(jìn)入正題。UEFI Shell腳本文件是.nsh后綴的純文本文件一行一條命令支持#注釋。我把語法拆成幾個相對獨(dú)立的部分來講。4.1 變量與環(huán)境變量%符號的用法UEFI Shell里所有變量都是環(huán)境變量沒有單獨(dú)的局部變量概念。你用它它就是一個全局的環(huán)境變量你刪它用set命令。設(shè)置和引用的語法set MYVAR hello echo %MYVAR%第一行把環(huán)境變量MYVAR設(shè)成hello第二行輸出hello。注意引用變量時必須用%包裹這和Windows批處理里的%VAR%寫法一樣。刪除變量用set MYVAR后面不跟值就是刪除?；蛘遱et -d MYVAR?？串?dāng)前所有環(huán)境變量直接敲set不帶參數(shù)。有一個必須記住的坑**環(huán)境變量的值里如果包含特殊字符解析順序會導(dǎo)致意想不到的結(jié)果。**Shell對%的解析是在執(zhí)行命令之前做替換所以如果你在腳本里想輸出一個字面上的%得寫兩個%轉(zhuǎn)義——echo %%輸出一個%。這一點(diǎn)和批處理腳本一模一樣。Shell自帶一些內(nèi)置變量經(jīng)常用到的有%path%可執(zhí)行文件搜索路徑多個目錄用分號分隔。%cwd%當(dāng)前工作目錄。%lasterror%上一條命令的返回值/錯誤碼。%startup%是否以startup.nsh方式啟動腳本里可以用它判斷當(dāng)前是不是開機(jī)自啟。我實(shí)際寫腳本用到%lasterror%的頻率非常高。因?yàn)槟_本本身沒有try-catch機(jī)制判斷命令是否執(zhí)行成功唯一的辦法就是檢查錯誤碼。4.2 腳本參數(shù)與shift處理執(zhí)行一個.nsh腳本時可以帶參數(shù)比如Shell test.nsh arg1 arg2在腳本內(nèi)部%0拿到的是腳本名自身%1到%9依次是參數(shù)1到參數(shù)9%*是全部參數(shù)從參數(shù)1開始。有一個比較坑的地方UEFI Shell雖然支持shift命令但它的shift不太好用——它是把參數(shù)整體左移一位%1變成原來的%2以此類推。如果你拿%1做循環(huán)取出所有參數(shù)寫到第三四個參數(shù)之后容易亂套。我自己寫腳本處理不定長參數(shù)時通常直接繞開%1~%9改用%*配合字符串截取操作。字符串操作指令在UEFI Shell里是%VAR:~start,len%這種風(fēng)格比如set fullarg %* set firsttwo %fullarg:~0,2%這可以截取參數(shù)的前兩個字符。語法風(fēng)格接近Windows批處理的%VAR:~m,n%。但因?yàn)镾hell對%的解析比較嚴(yán)格這種寫法在嵌套環(huán)境里偶爾會出問題。所以遇到特別復(fù)雜的字符串處理我更推薦在腳本里調(diào)用echo加重定向生成一個新的臨時腳本再執(zhí)行這個臨時腳本——雖然笨但可控。4.3 分支if/then/else/endifUEFI Shell的if語法支持三種基礎(chǔ)形式if 條件 then 命令 endifif 條件 then 命令 else 命令 endifif 條件 then 命令 elseif 條件 then 命令 endif條件判定的寫法分兩種。一種是判斷環(huán)境變量是否存在或等于某個值if %MYVAR% hello then echo match endif另一種是文件存在性判斷if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo found bootloader endif注意兩邊我習(xí)慣都加引號這是從批處理時代養(yǎng)成的習(xí)慣——如果%MYVAR%是空值不加引號會導(dǎo)致整個條件表達(dá)式語法不完整腳本會報錯。加了引號之后空值就變成了一個空字符串參與比較穩(wěn)妥很多。還有三個邏輯運(yùn)算符可以用AND、OR、NOT。比如if exist FS0:\flag.txt AND %mode% test then echo enter test mode endif4.4 循環(huán)for和whilefor循環(huán)的語法是for %i in (val1 val2 val3) echo %i endfor注意循環(huán)變量用單個%不是雙%for %i in (1 2 3 4) echo %i endfor如果想遍歷文件列表可以這么寫for %i in FS0:\*.nsh echo %i endforShell會自己展開通配符把匹配到的文件路徑依次賦給%i。while循環(huán)的語法也類似while 條件 命令 endwhile這里有一個重要限制UEFI Shell的循環(huán)沒有計數(shù)器自動遞增的能力如果你要用while計數(shù)必須自己修改變量。set counter 0 while %counter% 5 echo count is %counter% set counter %counter%1 endwhile等一下UEFI Shell的set命令不支持算術(shù)運(yùn)算。set counter %counter%1的結(jié)果是字符串01不是數(shù)字1。這是Shell腳本最讓人抓狂的地方——它沒有內(nèi)置的整數(shù)運(yùn)算能力。那怎么實(shí)現(xiàn)計數(shù)兩個辦法。一是借助for %i in (1 2 3 4 5)這種顯式列表實(shí)現(xiàn)固定次數(shù)循環(huán)二是用外部工具比如edk2自帶的parse命令或者其他小工具去處理數(shù)值。或者退一步循環(huán)次數(shù)已知就用for循環(huán)條件是基于環(huán)境變量且不需要自增的情況才用while。這個思路能讓你的腳本少走很多彎路。4.5 傳說中的goto和標(biāo)簽UEFI Shell支持goto跳轉(zhuǎn)和標(biāo)簽goto :start ... :start echo start here標(biāo)簽是冒號加名字goto語句跳轉(zhuǎn)到指定標(biāo)簽。注意goto不能跳出當(dāng)前腳本文件的邊界——你沒法在一個.nsh里goto到另一個.nsh的標(biāo)簽。這和批處理一樣。但goto在Shell里還有一個比較危險的行為如果標(biāo)簽不存在Shell不會報錯退出而是直接跳到腳本末尾然后返回一個%lasterror%錯誤碼。如果腳本是開機(jī)自啟動的startup.nsh這種靜默失敗很容易被忽略后面真正要用的操作沒執(zhí)行你還不明所以。4.6 把多個命令串起來重定向和管道UEFI Shell支持重定向是覆蓋寫是追加寫。比如把命令輸出保存到文件ls FS0:\filelist.txt smbiosview -b FS0:\smbios.txt管道|在UEFI Shell里的支持比我想象中弱一些。實(shí)測下來管道在某些版本的Shell里能工作在另一些版本里會直接報語法錯誤。比如ls | grep .efi這個命令在部分EDK2版本里能用Shell內(nèi)置了grep的簡易實(shí)現(xiàn)但換到另一塊主板上可能就失敗了。我的經(jīng)驗(yàn)是正式腳本里盡量少用管道需要過濾輸出就先把結(jié)果重定向到臨時文件再用search命令或type加parse去處理。寧可多寫兩行也不要在管道這個特性上賭固件實(shí)現(xiàn)。5. 一個能直接上機(jī)跑的診斷備份腳本逐步拆解語法講再多不如一個完整的例子。下面這個腳本是我在某次批量主板測試中實(shí)際用的一個簡化版本功能包括檢查設(shè)備映射、備份當(dāng)前BIOS區(qū)域模擬、收集SMBIOS信息、檢查關(guān)鍵啟動文件是否存在。5.1 腳本的目標(biāo)與運(yùn)行邏輯這個腳本解決一個很實(shí)際的問題現(xiàn)場運(yùn)維人員拿U盤插到機(jī)器上跑一下自動把診斷信息和備份文件落盤然后退出。不需要他們懂Shell命令不需要手動敲一堆指令。腳本放在U盤根目錄啟動進(jìn)入Shell后執(zhí)行FS0:\debug.nsh所有輸出寫到同一個日志目錄下。5.2 完整腳本內(nèi)容# debug.nsh - 簡易固件診斷與備份腳本 # 用法: debug.nsh [日志目錄] set LOGDIR %1 if %LOGDIR% then set LOGDIR FS0:\LOGS endif if not exist %LOGDIR% then mkdir %LOGDIR% endif set LOGFILE %LOGDIR%\debug_%lasterror%.log # 1. dump設(shè)備映射 echo %LOGFILE% echo Device Map %LOGFILE% map %LOGFILE% # 2. dump SMBIOS信息 echo %LOGFILE% echo SMBIOS Info %LOGFILE% smbiosview -b %LOGFILE% # 3. 檢查關(guān)鍵EFI啟動文件 echo %LOGFILE% echo Check BootLoaders %LOGFILE% set FOUND 0 if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo FS0: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif if exist FS1:\EFI\BOOT\BOOTX64.EFI then echo FS1: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif # 4. dump啟動項 echo %LOGFILE% echo Boot Option List %LOGFILE% bcfg boot dump %LOGFILE% # 5. 備份當(dāng)前啟動項配置 echo %LOGFILE% echo Boot Option Backup %LOGFILE% bcfg boot dump -v %LOGFILE% echo %LOGFILE% echo Done. Log saved to %LOGFILE% pause exit5.3 逐段講解為什么這樣寫參數(shù)與默認(rèn)值腳本開頭先取%1作為日志目錄如果沒傳參就默認(rèn)用FS0:\LOGS。這里用到了前面講過的空判斷技巧——if %LOGDIR% 空值時%LOGDIR%被替換成空字符串表達(dá)式就變成了if 成立進(jìn)入默認(rèn)賦值邏輯。日志文件的命名我在這里耍了個小聰明debug_%lasterror%.log。第一次執(zhí)行時%lasterror%可能為空或0第二次執(zhí)行時它等于上一次某個命令的返回值。這個命名其實(shí)不夠嚴(yán)謹(jǐn)最終生成的文件名可能不唯一但勝在簡單。嚴(yán)格一點(diǎn)的做法是用%time%或%date%拼一個時間戳但UEFI Shell里的時間格式依賴固件實(shí)現(xiàn)輸出經(jīng)常是10:20:30帶冒號Windows文件系統(tǒng)不認(rèn)冒號所以用時間戳反而容易踩坑。smbiosview -b參數(shù)smbiosview是EDK2自帶的SMBIOS查看命令-b表示分頁輸出。在重定向到文件時分頁參數(shù)不僅不會打斷輸出反而能讓內(nèi)容一次性完整落盤不會因?yàn)榭刂婆_緩沖區(qū)限制丟行。這個細(xì)節(jié)最開始我不知道導(dǎo)致dump出來的SMBIOS信息只有前幾行排查了半天。bcfg boot dumpbcfg是啟動項管理命令。bcfg boot dump列出當(dāng)前所有啟動項-v參數(shù)會輸出更詳細(xì)的信息比如關(guān)聯(lián)的設(shè)備路徑。這個命令對排查為什么開不了機(jī)類問題非常有用。注意bcfg在某些精簡固件里可能沒被編譯進(jìn)去如果提示命令不存在回頭看我第6節(jié)的排查方法。5.4 執(zhí)行與驗(yàn)證這個腳本寫完后實(shí)際執(zhí)行時我用了一個小技巧先在QEMU里跑一遍確認(rèn)語法沒問題再放到真實(shí)U盤上跑。QEMU里跑的時候第一次執(zhí)行會報一堆smbiosview: command not found之類的錯誤嗎其實(shí)不會因?yàn)镺VMF固件里帶了SHELL的完整命令集。但真機(jī)上確實(shí)可能缺命令所以我在腳本里做了一件事所有可能失敗的命令后面都靠%lasterror%去判斷。更關(guān)鍵的一點(diǎn)寫腳本時每條命令的返回值都是獨(dú)立的。比如mkdir %LOGDIR%在目錄已存在時會返回錯誤碼但這不影響腳本繼續(xù)執(zhí)行——Shell腳本默認(rèn)不會因?yàn)閱螚l命令失敗而中止除非你顯式寫-exit或使用abort命令。這也是很多新手感到困惑的地方明明上一行報錯腳本還是往下跑了。理解這一點(diǎn)就能明白為什么腳本里要手動檢查關(guān)鍵步驟的%lasterror%。6. 踩坑實(shí)錄六年UEFI Shell使用中遇到的典型問題這一部分單獨(dú)拎出來因?yàn)檫@些坑我?guī)缀醵紝?shí)實(shí)在在踩過每一類都花過不少時間排查。寫出來幫你省點(diǎn)時間。6.1 文件系統(tǒng)大小寫與路徑分隔符UEFI Shell的文件系統(tǒng)和UEFI規(guī)范一樣不區(qū)分大小寫但輸出時可能混合大小寫。有次我寫了一個判斷if exist fs0:\EFI\BOOT\BOOTX64.EFI then注意我寫的是小寫fs0。Shell能認(rèn)出這個盤符嗎在大多數(shù)固件實(shí)現(xiàn)里可以但有些嚴(yán)謹(jǐn)?shù)膶?shí)現(xiàn)可能要求必須用FS0:全部大寫。我的建議是腳本里統(tǒng)一用大寫盤符、大寫路徑分隔符避免在固件兼容性上賭運(yùn)氣。路徑分隔符一律用反斜杠\不要用正斜杠/。UEFI規(guī)范里正斜杠在某些上下文里有特殊含義比如作為參數(shù)前綴萬一你把路徑寫錯排查起來非常痛苦。6.2 命令找不到環(huán)境變量和當(dāng)前目錄的坑path環(huán)境變量影響Shell對可執(zhí)行文件的查找范圍。有次我腳本里用了一個自研的診斷.efi工具放在U盤的EFI\Tools目錄下。腳本第一行執(zhí)行set path FS0:\EFI\Tools;%path%結(jié)果下一行調(diào)用這個工具時Shell提示命令找不到。排查了半天發(fā)現(xiàn)是set path這個操作本身的問題——當(dāng)一個環(huán)境變量名是path時Shell在執(zhí)行set path ...之后當(dāng)前這條命令的解析還沒結(jié)束它用的還是舊的path。等到下一條命令時新的path才生效。這看起來很正常但問題在于腳本第一行設(shè)置path第二行就要用應(yīng)該沒問題啊后來發(fā)現(xiàn)真正的原因是UEFI Shell在解析腳本時某些實(shí)現(xiàn)會在每行執(zhí)行前重新讀取path變量而另一些實(shí)現(xiàn)只在腳本開始執(zhí)行時讀取一次path快照。第一種實(shí)現(xiàn)里你中途改path對后續(xù)行生效第二種實(shí)現(xiàn)里你必須把path設(shè)置放在腳本最開頭或者用一個外層的wrapper腳本去設(shè)置path再調(diào)用真正的腳本。 這個行為差異沒有寫在規(guī)范里純靠實(shí)測發(fā)現(xiàn)。現(xiàn)在的處理策略是把path設(shè)置獨(dú)立放在一個env.nsh文件里所有需要環(huán)境變量的腳本第一行都改成include env.nsh或直接復(fù)制那兩行set命令。繞開實(shí)現(xiàn)差異。6.3include指令別對它寄予太多希望UEFI Shell有一個include命令可以理解為類似C語言的#include。用法include FS0:\env.nsh但實(shí)測下來include在多個版本里行為不太穩(wěn)定有的要求被include的文件必須帶.nsh擴(kuò)展名否則拒絕執(zhí)行有的在相對路徑下解析失敗。而且它不能傳參數(shù)被include的腳本里%1~%9會被清空還是保留原調(diào)用者的參數(shù)不同版本表現(xiàn)不一樣。我后來基本不用include需要復(fù)用代碼就直接把內(nèi)容復(fù)制進(jìn)主腳本或者通過執(zhí)行子腳本的方式傳遞參數(shù)call FS0:\subtask.nsh %parm%call是執(zhí)行另一個腳本的正確姿勢它會等子腳本執(zhí)行完再回到當(dāng)前腳本繼續(xù)。雖然每啟動一次子腳本有開銷但在腳本規(guī)模不大的前提下可維護(hù)性比include強(qiáng)太多。6.4 腳本編碼與不可見字符UEFI Shell腳本文本文件的編碼要求不算嚴(yán)格但必須注意兩點(diǎn)。第一**保存為Unix換行LF還是Windows換行CRLF**實(shí)測而言Shell對兩種換行都能處理但混合換行會出問題。如果腳本在Windows下編輯完放到Linux環(huán)境改了一行再拷回U盤文件中同時出現(xiàn)LF和CRLFShell會在某些版本里把一個\r當(dāng)成命令的一部分導(dǎo)致命令不存在之類的報錯而且報錯指向的行和你實(shí)際出錯的行對不上——因?yàn)橹鹦薪馕鰰rCR被吞掉與否取決于實(shí)現(xiàn)。第二如果腳本里含非ASCII字符比如中文注釋必須在文件頭部加BOM否則Shell的文本解析可能亂碼。這個問題在UEFI Shell 2.0之后有所緩解但保險起見腳本里我一般只用純英文注釋。6.5%lasterror%的時效性%lasterror%變量在每條命令執(zhí)行后都會更新但它有個特點(diǎn)內(nèi)置變量對set命令本身也會被更新。也就是說你執(zhí)行set foo 1之后%lasterror%變成的是這次set是否成功的狀態(tài)而不是最初那條你想檢查的命令的狀態(tài)。所以正確的檢查姿勢是這樣的bcfg boot dump FS0:\boot.txt set ERRCODE %lasterror% if %ERRCODE% 0 then echo dump ok else echo dump failed with %ERRCODE% endif先把%lasterror%存到一個普通環(huán)境變量里再拿去判斷。直接寫if %lasterror% 0雖然也能用但中間一旦插入別的命令比如echo值可能已經(jīng)變了。還有一個小細(xì)節(jié)%lasterror%雖說是錯誤碼但Shell命令成功時的返回值不一定是0。有些命令返回的不是標(biāo)準(zhǔn)0而是自定義狀態(tài)碼。所以判斷成功時更可靠的方式是檢查輸出文件的內(nèi)容是不是符合預(yù)期而不是只看返回碼。6.6 內(nèi)存讀寫命令的危險性mm命令可以在Shell里直接讀寫物理內(nèi)存和IO端口Shell mm 0xE0000000 # 讀這個地址的內(nèi)容 Shell mm 0xE0000000 0x1F # 往這個地址寫0x1F這是固件調(diào)試的利器但也是最大的危險源。寫錯一個地址輕則系統(tǒng)死機(jī)重則把SPI Flash里的固件搞壞。我見過同事在調(diào)試時用mm往某個不知道是什么的地址寫了個值重啟后板子直接起不來最后靠編程器重新燒固件才救回來。在腳本里涉及mm操作我的建議是先dmem或mem把目標(biāo)區(qū)域讀一遍確認(rèn)地址有效。寫操作前人工確認(rèn)三次地址沒錯。不要在自動化腳本里放未驗(yàn)證的mm寫操作。操作完馬上reset重啟觀察不要繼續(xù)跑后面的腳本。6.7startup.nsh的自動執(zhí)行機(jī)制如果你把U盤插上Shell啟動時會自動嘗試執(zhí)行U盤根目錄下的startup.nsh。這是一個很方便的機(jī)制但也容易出事故。有一次我調(diào)試腳本把startup.nsh放到U盤根目錄內(nèi)容是一個死循環(huán)等待某個條件。結(jié)果每次開機(jī)進(jìn)Shell就卡死拔U盤都來不及——因?yàn)镾hell啟動時讀不到文件系統(tǒng)U盤被占住拔掉就報錯。最后只能重啟進(jìn)BIOS把啟動順序改成直接進(jìn)系統(tǒng)再把U盤格式化才解決。所以我對startup.nsh的態(tài)度是開發(fā)階段不要把調(diào)試腳本命名為startup.nsh用普通文件名手動執(zhí)行。需要自動執(zhí)行時startup.nsh里只放一個調(diào)用其他腳本的語句不要寫長邏輯。重要操作前先pause給你自己留一個取消執(zhí)行的機(jī)會。6.8 腳本超時與交互Shell腳本執(zhí)行過程中如果需要人工輸入通常用pause命令等按任意鍵。但pause在無人值守場景下會卡住整個流程。如果需要倒計時自動繼續(xù)可以寫一個循環(huán)配合stall命令單位是微秒實(shí)現(xiàn)延時set countdown 5 while %countdown% 0 echo Continue in %countdown% ... stall 1000000 set countdown ... endwhile這里有個矛盾set不支持算術(shù)運(yùn)算所以set countdown %countdown%-1是無效的。實(shí)際做法是把倒計時變量拆成多個if判斷或者干脆用固定次數(shù)的for循環(huán)。比如for %i in (5 4 3 2 1) echo Continue in %i ... stall 1000000 endfor這個方案最簡單既不依賴算術(shù)運(yùn)算也不容易出錯。7. 把Shell腳本用在自動化測試?yán)锏墓こ袒悸纷詈笠徊糠至牧脑趺窗?nsh腳本寫得像工程代碼而不是隨手寫的玩具。這幾年我在固件驗(yàn)證項目里逐漸摸索出一套自己的規(guī)范分享出來供參考。7.1 約定目錄結(jié)構(gòu)一個完整的U盤工具包目錄結(jié)構(gòu)建議如下FS0:\ ├── startup.nsh # 入口腳本可選 ├── scripts\ │ ├── common.nsh # 公共函數(shù)用call調(diào)用 │ ├── debug.nsh │ ├── backup.nsh │ └── flash.nsh ├── tools\ │ ├── shell.efi # 備用Shell │ ├── xxxdiag.efi # 自定義診斷工具 │ └── ... └── logs\ # 日志輸出目錄腳本里統(tǒng)一用scripts\和tools\的絕對路徑不要在幾十行里到處寫FS0:\這種硬編碼。如果U盤盤符變了比如插到不同USB口變成FS1:至少還有救——你只需要改頂部的幾個set變量。7.2 輸出規(guī)范與日志級別UEFI Shell的echo命令沒有彩色輸出也沒法區(qū)分日志級別。我的做法是在腳本里統(tǒng)一一個日志函數(shù)的概念用子腳本實(shí)現(xiàn):log_info echo [INFO] %1 %LOGFILE% goto :EOF但前面說過goto :EOF在UEFI Shell里的支持不完全可靠所以這種函數(shù)寫法我很少用。更實(shí)際的做法是每條輸出都同時打到屏幕和日志文件屏幕輸出幫助操作者實(shí)時了解進(jìn)展日志文件用于事后審計。具體寫法是這樣echo Step 1: dump smbios... | tee %LOGFILE%等等tee命令在UEFI Shell里通常沒有。所以實(shí)際做法是寫兩行echo Step 1: dump smbios... %LOGFILE% echo Step 1: dump smbios...麻煩是麻煩一點(diǎn)但可靠。我已經(jīng)不指望Shell腳本能寫出多優(yōu)雅的日志框架了能穩(wěn)定執(zhí)行比什么都強(qiáng)。7.3 與UEFI固件內(nèi)部的交互變量命名空間環(huán)境變量名不要起得太通用。比如你腳本里用了一個set boot后面某段代碼也用了set boot互相覆蓋了排查起來非常費(fèi)勁。我建議所有腳本變量統(tǒng)一加前綴比如項目名縮寫set DBG_LOGDIR FS0:\LOGS set DBG_MODE 1這樣不同腳本之間的變量沖突概率大大降低。另外注意UEFI Shell的環(huán)境變量會隨腳本退出而保留除非你顯式刪除或整個Shell重啟。也就是說一個腳本設(shè)置的變量另一個腳本能看到。這既是便利也是隱患——一個寫壞了的變量可能在半小時后的另一個腳本里莫名出現(xiàn)。7.4 錯誤碼傳遞與失敗處理腳本失敗時的退出碼是%lasterror%。在自動化測試框架里我們經(jīng)常在Shell腳本的最外層套一個Linux或Windows側(cè)的驅(qū)動腳本用串口或網(wǎng)絡(luò)和Shell交互。Shell側(cè)接收參數(shù)、執(zhí)行測試、返回錯誤碼宿主側(cè)解析。這種模式下exit %lasterror%就非常關(guān)鍵確保Shell退出時把最后的錯誤碼帶出去。但有兩點(diǎn)要特別小心不是所有版本的Shell都支持exit %lasterror%的語法。部分實(shí)現(xiàn)只支持exit不帶參數(shù)返回碼永遠(yuǎn)是0。如果你在.nsh里執(zhí)行了另一個.efi程序該程序的退出碼會通過%lasterror%暴露出來但前提是Shell沒在這之間執(zhí)行其他命令。任何一條命令都可能覆蓋它。為了確保錯誤碼正確傳遞在測試框架里我會專門寫一個report.nshset TEST_RESULT %lasterror% if %TEST_RESULT% 0 then echo PASS FS0:\logs\result.txt else echo FAIL:%TEST_RESULT% FS0:\logs\result.txt endif exit %TEST_RESULT%宿主側(cè)的腳本只認(rèn)result.txt里的內(nèi)容不依賴Shell退出碼——因?yàn)閷?shí)測下來有的固件版本退出碼頭幾位的字節(jié)會被截斷導(dǎo)致宿主側(cè)收到奇怪的值。7.5 與DXE驅(qū)動和EFI應(yīng)用的配合UEFI Shell最有意思的地方是可以加載DXE驅(qū)動和運(yùn)行各種EFI應(yīng)用。比如在測試過程中你可能需要先加載一個自定義的協(xié)議驅(qū)動再跑測試工具。典型寫法load FS0:\tools\MyDriver.efi if %lasterror% 0 then echo driver loaded else echo driver load failed endifload命令加載驅(qū)動后驅(qū)動常駐內(nèi)存。此時可以用drivers命令查看驅(qū)動列表用devices查看設(shè)備節(jié)點(diǎn)。如果有新設(shè)備出現(xiàn)說明驅(qū)動生效了。加載驅(qū)動時特別需要注意驅(qū)動一旦加載成功直到系統(tǒng)重啟前都不會被卸載。你連續(xù)加載同一驅(qū)動兩次第二次會返回錯誤但這個錯誤并不影響第一次加載的效果。所以腳本里不要因?yàn)槟炒渭虞d報錯就判定驅(qū)動有問題要結(jié)合drivers輸出確認(rèn)是否已在列表里。7.6 QEMU聯(lián)調(diào)不燒板子練腳本最后安利一下QEMU調(diào)試法。EDK2項目官方就提供OVMF固件配合QEMU可以完整模擬UEFI環(huán)境。具體步驟下載編譯好的OVMF.fd固件或者自己從EDK2源碼編譯。準(zhǔn)備一個FAT32格式的磁盤鏡像把寫好的.nsh文件放進(jìn)去。啟動命令大致是qemu-system-x86_64 -drive ifpflash,formatraw,fileOVMF.fd -drive formatraw,filefat:rw:./diskQEMU啟動時會自動進(jìn)入OVMF的菜單選擇UEFI Shell即可。這個方法有兩個好處一是完全不用碰真實(shí)硬件腳本寫錯了重啟一下虛擬機(jī)就行二是QEMU支持GDB調(diào)試你可以結(jié)合EDK2源碼單步跟蹤Shell命令的執(zhí)行流程理解每一條命令背后的邏輯。不過對大多數(shù)應(yīng)用場景來說能快速驗(yàn)證語法就夠了也不必深入到那個程度。8. 最后分享幾個關(guān)于Shell腳本的心得回想這幾年跟UEFI Shell打交道的經(jīng)歷最深的感觸是這工具看著像Linux終端用起來像DOS批處理但它的很多細(xì)節(jié)都夾在固件實(shí)現(xiàn)和硬件平臺的縫隙里。同一個腳本在這塊板子上跑得好好的換一塊板子可能就行為迥異。所以我的建議一直沒變——腳本要向最基礎(chǔ)的命令看齊不要賭固件實(shí)現(xiàn)的一致性和文檔沒有覆蓋的邊界行為。具體到日常使用有幾件事是我每次上手都會做的拿到一臺新機(jī)器先敲ver看Shell版本再敲map看設(shè)備最后ls -?、bcfg -?看命令支持情況。花五分鐘快速評估這臺機(jī)器的Shell能力邊界比后面盲寫腳本踩坑強(qiáng)得多。寫任何涉及硬件操作的腳本前先在虛擬機(jī)里跑通邏輯再在真機(jī)上人工跑一遍驗(yàn)證命令可用性和輸出格式最后才正式使用。遇到詭異問題先用type或hexedit看腳本文本有沒有不可見字符然后再懷疑語法。這個排查路徑能解決相當(dāng)一部分奇怪的問題。如果你平時做BIOS開發(fā)或固件測試UEFI Shell腳本看著不起眼但熟練之后真的能幫你把很多重復(fù)的調(diào)試工作變成一條命令的事。把這篇文章里的語法和踩坑點(diǎn)消化掉你大概率就能寫出屬于自己的第一版可復(fù)用腳本了。