PowerShell 通配符 Get-Item 無法帶有方括號名稱的檔案

這算是 PowerShell 5.1 預設給的方便的，不過在不知情的情況下就造成bug了

假設有一個 [1]File.txt 的檔案，於是就這樣獲取

Get-Item [1]File.txt

居然什麼都沒有，於是乎聰明如你，用引號總能解吧?

Get-Item "[1]File.txt"
Get-Item '[1]File.txt'

想不到吧很遺憾還是沒有辦法

這東西叫做通配符，內建在 Get-Item 裡的所才沒法通過引號處理的
about Wildcards - PowerShell | Microsoft Learn

情況1

如果你只是單純想解決括號問題，沒有要搞通配符號組合，參考這個就能解了。

# 使用函式接口 LiteralPath (就是拒用萬用符拉)
Get-Item -LiteralPath 'Test[1]'.txt

# 連帶反轉意符號一起傳進去
Get-Item '.\Test`[1`].txt'

# 如果用雙引號圍住的話傳入前就會被解掉要多2個反引號
Get-Item ".\Test```[1```].txt"

情況2

另一個坑是當括號與星號一起出現時，又會導致另一個解析問題，括號被當作通佩服一起解釋了，就是你想匹配 Test[*].txt 多個檔案的時候。

這時候情況更複雜了一些，你得連反引號都一起傳進去才能，免得反引號在傳入的當下被解析了少了一次解析。

# 連帶反轉意符號一起傳進去
Get-Item '.\Test``[*``].txt'

# 雙引號的話更精彩一點，堪稱這在衝三小
Get-Item ".\Test`````[*`````].txt"

測試結果

情況3

2024-09-28 發現一個新問題 'Test``[*``].txt' 實際上匹配的並不是 Test[*].txt 而是 Test*.txt，說起來繞口，原因是那個方括號被當作萬用字解讀了。

如何更明白的理解問題可以看下面這個例子

# 匹配檔名為 Test[0].txt, Test[1].txt 的檔案
Get-Item '.\Test``[[0-1]``].txt'

這樣寫出來應該就很好理解了，因為萬用字的匹配是在 cmdlet 裡面做的，所以才導致這個反人類思維的解...

第一層反引號會在傳入的時候被解掉，此時算法實際吃到的是一個反引號的 `[ 所以她成功識別是一個引號，第二個由於就是引號沒什麼好說的吃到引號當作萬用字解讀。

也就是可以理解成 [0-1] 這東西會被當作一個特殊字串對待，剩下的保持原本模樣。

那為什麼 '.\Test`[1`].txt' 能夠被正確識別呢? 因為 [1] 沒有構成合法的萬用字元所以被當作字串解讀了 (這鬼邏輯...雖然是正確的但別這樣設計搞人啊)

情況4

以為這樣就結束了嗎? 不還有一個更鬼畜，記得先溫得好情況3的神奇邏輯，這是同一套邏輯的變態版，現在考慮到檔名含有雙引號的情況

# 匹配檔名為 Test`[0].txt, Test`[1].txt 的檔案
Get-Item '.\Test``````[[0-1]``].txt'

居然是要添加4個引號? 是的這個邏輯的是正確，因為傳入的時候會被吃掉一次只剩2個，真正在運算的時候又被吃掉一次只剩1個，所以正確的識別了

這個鬼邏輯來自於，不知道為啥路徑相關的cmdlet會對路徑做一次多餘的雙引號解析導致的，啥原因設計成這樣就不知道了。

下面是測試的方法，看了應該就秒懂上面的情況4 發生什麼事情了
(注意雙引號與單引號)

# 模擬 Get-Item 是如何處理萬用字元的
'.\Test`[1].txt' -like ".\Test``````[[0-1]``].txt"

對他們是相等的...也就是說對於所有路徑相關的 Get-Item, Test-Path 等等必須自己有自覺的認識到，即使我用了單引號避免被解釋，但實務上進去還會被解析一次。

這個真該打屁股了誰寫的反人類設計...

不過嘴砲歸嘴砲，八成是身處歷史當下的那群人，遇到某個無法解決的問題，提出的無可奈何的解吧...。現在好拉已經過這麼久了，想修估計也改不了了，成為萬世毒瘤了

對於這個局面的處置方法

對於這個局面要人性化的處置可以參考這下面這個解法

# 匹配的真實路徑 Test`[1].txt
Test-Path ('Test```[[0-1]`].txt' -replace('`','``'))
Test-Path ('Test```[*`].txt' -replace('`','``'))

這少這樣理解度就高一點了，為什麼會有三個是因為需要反轉意一個反引號跟方括號導致的，是可以讀懂的代碼。

深挖bug的本質

2024-10-09

這就完事了嗎? 並沒有，我又再次深入地去挖掘這個問題，發現老早就一堆人在講了

但是呢六年過去還是沒修，八成是因為歷史包袱改不了了。最大的絆腳石應該是因為

永遠都無法區分路徑字串上的 D:\test\Test`[0-2] 反引號到底是跳脫字元還是普通字符。

回到剛剛的話題為什麼這事情還沒完是因為，我們已經知道雙重跳脫可以協助我們區分到底誰是字元誰是跳脫

D:\test\Test```[0-2`]

我們上個色就知道誰是跳脫了，看上去很美好對吧，但是並沒有 PowerShell 在遇到反引號加上一個任意字符，再加上一個右方括號的時候，bug就由此而生

我找了很久還是沒找到這到底對應到哪個路徑，最後才發現

D:\test\Test```[0-2`] 可以找到 D:\test\Test`[0-2] 這個帶反引號的資料夾，但是但是

D:\test\Test```[0-2`]\File.txt 不能找到 D:\test\Test`[0-2]\File.txt 的檔案

很神奇吧，所謂的雙重引號只有最右邊的斜線有效而已，如果是中間層級的資料夾，雙重反引號是無效的。

好在社群有人發現另一個有趣的現象是，-include 的邏輯跟 -like 一樣是沒有雙重反引號的，我們可以鑽這個空子

function fix_get_item($Path){
    $dir  = (Split-Path $Path) -replace('`','``')
    $file = (Split-Path $Path -Leaf)
    $type = (Get-Item -Path $dir).PSProvider.Name
    (Get-ChildItem $dir -Recurse -Depth 1 -Include $file).FullName
} # fix_get_item 'D:\test\Test```[0-2`]\README`[[0-2]`].md'

利用 Get-ChildItem 去帶的好處是

for迴圈交由 Get-ChildItem 處理絕對比自己正則快很多很多
不需要去理會邏輯部分，交由現成的函式去處理
現在父資料跑到最右邊，父資料夾也支持奇耙路徑了 (反引號-任意字符-右方括號)

不過問題淺顯易見，爺資料夾以上還是只能使用正常路徑+通配符，但這問題不大已經足夠覆蓋絕大多數的情況了。

參考

Wildcard matching when filename has square brackets · PowerShell/PowerShell · Discussion #18146 (github.com)

CHG

2024年6月6日星期四