作者falcon (falken)
看板Windows
標題Re: [心得] PowerShell 那些惱人的路徑 BUG
時間Fri Oct 11 03:23:22 2024
經過一些嘗試之後找到了一個方法來為 cmdlet 修復工作目錄路徑問題
儘管看起很蠢，但是管用
至於可不可靠，那就不知道了
# 為同名 cmdlet 修復工作目錄路徑問題
function Get-Item {
# 不能使用 [Parameter()] 修飾參數
# 否則，未宣告的參數會被拒絕
param (
[string[]] $Path,
[string[]] $LiteralPath
)
# 重現以下幾種管道功能
# $pathArray | cmdlet
# $pathArray | cmdlet -Path {$_}
# $pathArray | cmdlet -LiteralPath {$_}
[string[]] $vlueFromPipeLine = $input | ForEach-Object { $_ }
if ($vlueFromPipeLine.Count -gt 0) {
if ($null -ne $LiteralPath -and $LiteralPath[0] -eq '$_') {
$LiteralPath = $vlueFromPipeLine
}
elseif ($null -eq $Path -or $Path[0] -eq '$_') {
$Path = $vlueFromPipeLine
}
else {
Write-Error ''
return
}
}
$param = @{}
if ($LiteralPath.Count -gt 0) {
$param += @{
LiteralPath = $LiteralPath | ForEach-Object {
# 展開為路徑為 PSDrive:\path\to\item
}
}
}
if ($Path.Count -gt 0) {
$param += @{
Path = $Path | ForEach-Object {
# 展開為路徑為 PSDrive:\path\to\item
# 展開的部分要對特殊字元跳脫處理
}
}
}
# 呼叫 cmdlet 執行修改過的參數內容
Microsoft.PowerShell.Management\Get-Item @param @args
}
另外我還發現 Start-Process 下面三個路徑參數壞得更徹底
只要有特殊字元就發生錯誤，連跳脫處理都無效
-RedirectStandardError
-RedirectStandardInput
-RedirectStandardOutput
PowerShell 處處都是地雷......
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 39.9.131.112 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Windows/M.1728588204.A.E74.html
1F：→ hunandy14: 代理這事我找到方法解決了，動態抽取出來劫持10/11 13:54
2F：→ hunandy14: 確定可以實現完美轉發了，中間自己加料就好10/11 13:56
3F：→ hunandy14: using namespace System.Management.Automation10/11 13:59
4F：→ hunandy14: $m = [CommandMetadata]::new((Get-Command Get-Item))10/11 13:59
5F：→ hunandy14: $script = [ProxyCommand]::Create($m)10/11 14:00
6F：→ hunandy14: 剩下的你應該知道我想幹嘛了XD 動態劫持並重載fun10/11 14:01
7F：→ hunandy14: 代理的元函式的輸入 函式名,{劫持參數:{代碼塊}}10/11 14:39
8F：→ hunandy14: 輸出看要輸出修改後的塊，還是不輸出直接注入10/11 14:39
感謝
但我不知道這怎麼做，有沒有範例參考?
受此啟發，我想到方法是這樣
using namespace System.Management.Automation
function Get-Item {
$command = Get-Command Microsoft.PowerShell.Management\Get-Item
$strCmdletBindingAttribute =
[ProxyCommand]::GetCmdletBindingAttribute($command)
$strParamBlock = [ProxyCommand]::GetParamBlock($command)
$otherBlocks = {
# 修改 $PSBoundParameters
Microsoft.PowerShell.Management\Get-Item @PSBoundParameters
}
$strScript = "$strCmdletBindingAttribute`nparam($strParamBlock)`n" +
$otherBlocks.ToString()
$script = [Scriptblock]::Create($strScript)
& $script @args
}
※ 編輯: falcon (27.247.32.27 臺灣), 10/11/2024 17:19:37
我發現這個方法會影響一些命令相關的 cmdlet
例如 Get-Help, Get-Command
另外，我還發現 Module 的作用範圍好像超乎預期的大
假如我匯入兩個 Module 如下
# module-a.psm1
function SaySomething {
'Hello! World!'
}
# module-b.psm1
function TryToSaySomething {
SaySomething
}
# Console
PS > Import-Module .\module-a.psm1
PS > Import-Module .\module-b.psm1
PS > TryToSaySomething
Hello! World!
引用 module_b 的函式時，也會受到 module_a 的影響
也就是說我在模組中定義一個函式用來代替 cmdlet
這個影響不只目前腳本，還將遍及所有其它的模組
這不知道該開心還是難過
※ 編輯: falcon (27.247.32.27 臺灣), 10/11/2024 21:36:43
9F：→ hunandy14: 準確的來說不是影響到模組，而是影響到環境10/12 01:18
10F：→ hunandy14: 蓋掉原始函式這事情很大，任何情況都不建議10/12 01:19
我放棄了安裝使用的念頭，風險太大了
但在個別腳本或臨時匯入使用
高度可控的情況下應該比較沒問題
11F：→ hunandy14: 就算200%確定無bug 考慮到utf8補完計畫 就..真的慎選10/12 01:22
感謝示範技巧，有空來研究看看
現在想想
還是使用 -LiteralPath 與絕對路徑最妥當
遇到萬用字元或相對路徑
就用自己實作解析函式取得絕對路徑
再餵給 cmdlet
14F：→ labbat: 放棄掙扎投入標準UTF-8唄，UCS-2之上的任何補完都是徒勞10/13 02:25
15F：→ smallreader: 什麼都4202年了竟然還有UTF-8的坑要跳？！10/13 04:16
※ 編輯: falcon (27.51.88.255 臺灣), 10/13/2024 13:23:22
16F：→ hunandy14: 等等 前面講得太簡短，我想說的不是utf8的問題。覆蓋函 10/13 14:20
17F：→ hunandy14: 式的做法導致自己寫的代碼只能在這種被覆蓋的環境下執 10/13 14:20
18F：→ hunandy14: 行，相對短期來看沒問題，長期來看或許會留下隱形的成10/13 14:20
19F：→ hunandy14: 本。10/13 14:20
20F：→ hunandy14: 補完計劃的事先當我沒說，模糊焦點了。10/13 14:27
21F：→ falcon: 不過，對於外部程式要避免路徑與管道問題，也只能使用 10/13 17:26
22F：→ falcon: Process 物件來啟動程式。但之前提供的方法用在某些程式上10/13 17:26
23F：→ falcon: 會遇到死鎖WaitForExit()的問題，例如iconv.exe。要避免這10/13 17:26
24F：→ falcon: 問題，是需要用到非同步或多執行緒讀寫管道？10/13 17:26
※ 編輯: falcon (27.51.88.255 臺灣), 10/13/2024 20:57:56
25F：→ hunandy14: 第一推薦的做法是查一下有沒有 -oBatchMode=yes 的選項 10/14 08:53
26F：→ hunandy14: 第二推薦的辦法是測一下給空白本身會不會報錯 10/14 08:54
27F：→ hunandy14: 如果答案是會，那就直接關掉輸入他自己就會報錯了 10/14 08:54
28F：→ hunandy14: 第一個是完全解完全不需要考慮會不會bug 10/14 08:55
29F：→ hunandy14: 第二個可能要想一下組合考慮後果了未必可行 10/14 08:56