Windows PowerShell
サーバとしてのWindowsについてよく言われる批判の一つに、管理ツールすらGUIでしか提供されていないため、CUIを使ってリモートから管理することが殆んど出来ないことがある。Microsoftもそこを認識しているようで、Exchange Server 2007ではCUI管理ツールが大幅に強化されて、X上で動く多くのソフトウェアのように、GUIのツールはCUIのツールのフロントエンドとして作られるようだ。それと合わせて、対話的な用途にも、スクリプトとしてのバッチ用途にも非力なcmd.exeに代わり、新たなシェルが提供されることになった。それがhttp://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspxである。
1.0がリリースされたのは知っていても、Windowsを使っていなくては試すことも出来ず、殆んど知らなかったのだけど、Wikipediaでシェル関係を漁っていたら偶然PowerShell - Wikipediaにたどり着き、読んでみたら非常に面白く、その勢いで@ITの特集も読んでしまった。
このPowerShellで興味深かった点は3つ。1つ目は、.NETのクラスライブラリを扱えるように、シェルスクリプトのための構文*1がいわゆるPOSIX.2で規定されているようなUnix shell*2と、C#を合わせたようなものになっていること。
2つ目は、DOSがUnixからdevファイルのマウントという概念を輸入しなかったために生まれた分かりやすいが美しくないドライブレターを拡張したprovider*3という概念。これはPowerShellでなくAPIである.NET以下の層で実装した方がprocfsとかFUSEみたいに任意の.NET上のソフトウェアからアクセス出来て面白そうな気もするけど、過去の遺物かと思っていたものがこんな一貫性のある拡張をされるとは思わなかったので驚き。
3つ目が、一見標準入出力がUnix以来の伝統である文字列を含むバイトストリームから、.NETのオブジェクトに拡張されたかのようなパイプ*4。実際はオブジェクトをやりとり出来るのはPowerShellによって扱われる仮想クラスCmdletの実装であるcmdletsの間だけらしく、出力先が非cmdletsであるコマンド、端末、ファイルの場合はPowerShellによって*.Format.ps1xmlに応じた文字列への変換が暗黙になされる*5ようだ。
あと、Windows PowerShell SDK | Microsoft Docsを読んでいて、Cmdletに実装する必要がある3つのメソッドBeginProcessing、ProcessRecord、EndProcessingがawkのBEGINパターン、パターンなし、ENDパターンと非常に類似していることに気付いたんだけど、思えば、行指向のsedから、$RSと$FSを使うことによって、フィールドの並びとしてのレコード指向へと移行したのがawkの大きな特徴の一つなので、cmdletsをレコードを.NETのオブジェクトに拡張したAWK.NET(仮)として認識することにするとわりとイメージに合う気がした。
てなわけで、シェル、スクリプト言語&環境としてWindows持ってない自分でも興味深いと思えるPowerShellなんだけど、Cygwin使用者の多くがWindows標準の端末エミュレータ(と言うよりいわゆるDOS窓)に満足できずにPoderosa、CygTerm、ck、PuTTYcygを使っていたという事実を思い出すと、CUIで本格的に使えるOSへの脱皮にはまだ結構な道のりがあるんじゃないか、という気がする。少なくとも、ラインエディタにEmacsとviキーバインドの両方*6を用意するのは必須だろう。
*1:http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellQuickStart
*2:http://www.opengroup.org/onlinepubs/009695399/idx/shell.html
*3:http://www.atmarkit.co.jp/fdotnet/special/powershell01/powershell01_02.html
*4:http://www.atmarkit.co.jp/fdotnet/special/powershell02/powershell02_02.html
