在寫作的時候有兩個答案(一個來自吉文Levy和一個從jon Z),儘管事實上Shay的回答已經被接受(!),但兩者都很接近,但都不是很正確。這裏的原因:
與吉文的代碼問題
吉文的回答是太乏味了,基於指定創建這個「可能有這樣的條目哈希表」的不準確陳述要求:
@(Key=Mailcomp,Value=BL_2.1.0.9.5179)
@(Key=OfficeComp, Value=BL_2.1.0.17.6972)
但是,如果有人打算使用PowerShell語法,則說明不正確。在現實中,要求應該是這樣的:
也就是說,第一行指定哈希的Mailcomp
關鍵和哈希值的BL_2.1.0.9.5179
。的吉文的這段代碼修改後的版本提供了恰恰是:
$hash = @{}
Get-Content $BaselineFile |
Foreach-Object {
if ($_ -match '^\(([^@]+).+\)\s([^@]+)')
{
$hash[$matches[1]]=$matches[2]
}
}
下面是輸出:
Name Value
---- -----
Mailcomp BL_2.1.0.9.5179
OfficeComp BL_2.1.0.17.6972
這是很容易的工作,因爲我現在可以訪問$hash["Mailcomp"]
或$hash["OfficeComp"]
檢索它們各自的值。
Shay的代碼的第二個問題是哈希條目創建本身(@{ key=$matches[1]; value=$matches[2] }
)。該語句爲每次迭代(即輸入的每一行)創建一個單獨的「小」散列表。它只有似乎由於其代碼中隱式寫入輸出的合併而產生合理的輸出。爲了證明這一點 - 和蘋果比較蘋果 - 採取我上面的代碼,並與此等同於吉文的代碼代替條件:
if ($_ -match '^\(([^@]+).+\)\s([^@]+)')
{
@{ $matches[1]=$matches[2] }
}
你會發現,$hash["Mailcomp"]
不不返回預期BL_2.1.0.9.5179
。
與喬恩的代碼
我喜歡喬恩個Z回答的問題;我真的這樣做。真。但它讓我想起了這句偉大的笑話assume we have a can opener...這是一個非常好的解決方案,當且僅當輸入適合一個簡單的分隔符。這裏不是這種情況 - 需要使用正則表達式(或其他機制)來處理輸入。平心而論,喬恩明確表示他正在進行一些預處理。 「Nuff說。
我會驗證並做必要的修改,接受最佳答案 – Samselvaprabu 2012-01-10 03:13:49