引子

一直很羨慕Linux的命令提示符（當然他們叫Shell）。正則表達式，管道，各種神奇的命令，組合起來就能高效完成很多復雜的任務。效率實在是高。流了n年的哈喇子以后，終于有幸用上了Win7，邂逅了cmd的升級版：Windows PowerShell。從此暗爽無比，原來Windows下也有這樣的利器呀~
看看下面的Windows腳本，不到15行有效代碼。在Win7下只要右擊腳本文件，選擇Run with PowerShell，就會自動找到最占內存的10個進程，然后將它們占用的內存畫成一個三維餅圖，如下圖所示。

（1. 這個腳本調用了Excel的COM庫。 2. 當然從命令耦合的角度來看，輸出成文本格式更有利，但這個例子主要想說明PowerShell的強大以及微軟產品優異的復用性。 3. 要手動啟動PowerShell，可以在開始菜單的搜索框中直接鍵入PowerShell回車即可）
簡單領略PowerShell的強大之后，下文就從幾個方面介紹一下PowerShell相對于以往版本的命令提示符甚至Linux Shell的優勢。

Cmdlet + Regex + Pipeline + ...

以往cmd相對于Shell有很多不足，比如命令偏少，部分命令功能偏弱，對正則表達式不支持等等。但現在PowerShell一下趕上來不少。2.0 RTM版內建支持414個命令（術語稱為cmdlet），支持正則表達式，強大的管道應用（其實管道本身的功能和以前差不多，關鍵是冒出來一堆能用管道的命令，比如more, sort, foreach等等），和系統的聯系也比以前緊密了很多。

舉幾個例子來說明：

dir registry::HKEY_CURRENT_USER可以直接顯示注冊表相應位置的內容，可以看到dir的功能改進了不少。

ps | sort ws -Descending | select -first 10可以顯示占用內存最大的10個進程，可以看到管道的靈活應用。

dir -Name | ? {$_ -match "(?num>.).*(\knum>)"}可以顯示出當前目錄下文件名有重復字符的文件。比如abcda.efg，而abcd.efg則不會顯示出來。可以看到PowerShell對正則表達式的支持相當強大。（確切的說嚴格的正則表達式 已經無法實現這樣的效果，需要上下文無關文法 才能夠支持。）
以前為了演示Linux Shell的強大，Stephenjy發了一個自己的截圖，在遇見PowerShell前覺得好神奇，所幸現在也可以實現了。:-)

(為了節約顯示空間，PowerShell的部分顯示結果被刪除，但這個Prompt效果可以用以下腳本驗證: function prompt {"($env:username)-($env:computername)-(`$?: $?)-(jobs: $((get-job | measure).Count))-($(get-location))`n(! $(((history)[-1]).ID + 1))->"})

大殺器 - 面向對象

Linux的設計思想決定所有的輸入和輸出都盡可能是文本格式，這樣可以方便各進程間的合作。同樣這也要求各個程序提供一定強度的文本解析能力。但Windows的思想與此不同，PowerShell中很多輸入輸出都不是普通的文本(plain text)，而是一個個對象(objects)。因此與其說PowerShell是一種交互環境，不如說它是一種強大語言的Runtime，而這種語言甚至是面向對象的。

比如當鍵入get-process查看當前進程列表時，系統返回的是這樣的列表：

雖然看似一般的格式化文本，但其實這是一個數組，而每個數組元素又是Process類型的對象。同.NET一脈相承，PowerShell中的所有的類都繼承自Object，且支持GetType()函數。因此我們可以執行(get-process).GetType()來看看它的類型：

站在巨人的肩膀上 - 無縫調用.NET/COM

.NET Framework中包含了一個異常強大的庫，而微軟為了保證二進制層面上跨語言的兼容性，很多庫都是用COM封裝的。PowerShell的一大特色就是可以直接調用這些庫。比如前面的示例用$objExcel = New-Object -comobject Excel.Application創建了一個Excel對象。而wikipedia上的一個腳本更示范了這種無縫調用的強大。下面這個3句話的腳本的作用是顯示一個RSS源最近的8篇文章的標題。注意其中網絡連接，內容下載，XML解析等工作全部由.NET庫完成，正因為站在巨人的肩膀上，PowerShell在實際使用中往往左右逢源，簡潔高效。

編輯，運行，調試 - IDE

Windows程序開發，尤其是基于微軟技術的開發很爽的一點就是有強大的IDE和專業的文檔作支持。不論是Windows下的Visual Studio還是Linux下的Mono Develop，甚至連PowerShell這樣的語言都有集編輯與調試為一體的IDE：Windows PowerShell ISE。有了自動完成，即時腳本交互，調試甚至遠程調試，PowerShell腳本寫起來“甚爽甚強巨”。當然文檔也是一般的強大，MSDN中關于PowerShell的部分依舊專業浩瀚。

蛋疼的偽裝 - Profile

有了PowerShell以后，很少就去cmd了。不過作為一個蛋疼的裝B男，把PowerShell偽裝成cmd也是挺有樂趣的一件事。不難發現PowerShell和cmd僅僅在圖標，標題，背景色，提示符，以及剛啟動時的顯示文字五個方面不同。圖標和背景色在快捷方式屬性中可以很方便的修改。而標題和提示符的修改就要用到Profile了。所謂Profile就是在每次啟動PowerShell時都首先自動運行的一段腳本。這個腳本的路徑在$profile變量中有設定。只要設定$host.UI.RawUI.WindowTitle為C:\windows\system32\cmd.exe就能將標題偽裝為cmd。而自定義提示符為當前路徑在PowerShell中自然萬分簡單。至于啟動時的顯示文字，只要通過/nologo參數隱藏原有的版本信息，再打印一行cmd中的文字就好了。最終效果如圖：（關于Profile，可以參見這個鏈接）

另：進程級工作調度 – 并行支持？

==========================================================
隨著多核處理器的迅速發展，從.NET Framework 4.0開始，并行計算被一再強調。從System.Threading中新增加的并行工具類到F#這種非常適合并行化的函數式語言，微軟適時對線程級并行提供了強大的支持。但是對于進程級的工作調度，Windows似乎還相當原始。舉個最簡單的例子來說，如果我們同時向一個移動硬盤啟動5個拷貝會話的話，Windows會同時開始所有的拷貝操作。這樣磁頭會在不同的目標位置間反復進行無意義的移動（尋道），于是在硬盤燈的狂閃中，大量時間就被浪費了。同樣當我們同時啟動數個計算量大的進程時，Windows也會試圖讓這些進程“齊頭并進”。然而為了避免某個進程被餓死，系統又不得不頻繁切換進程，于是大量的時間又被浪費在了保存現場，進程切換，恢復現場上。這樣來看，進程級的并行做的反而不夠好。

所幸PowerShell中加入了任務調度管理功能。通過簡單的實驗，我們可以發現PowerShell對jobs的調度和Windows默認的大不相同，它一般維持和CPU核心數相同的進程高速運轉，而其它進程僅僅占用小部分CPU時間。直到前面的進程結束工作后，后面才有新的進程遞補進入高速運轉的狀態。==========================================================
后來更仔細地做了實驗以后發現，原來Windows內置的進程調度方案就是小部分高速運轉（在我的雙核處理器上是兩個進程占用50%CPU），大部分低速跟進（其他所有進程分享剩下的50%CPU）。這樣PowerShell的工作調度并沒有改善系統原有的現狀。同時由于PowerShell的調度系統需要占用不小的內存，初始化也需要時間。在實測中甚至比默認調度慢了50%。這個實驗結果比較囧。不曉得為什么PowerShell中為什么要加入Job這個東西，難道僅僅為了異步調用嗎？