RSS2.02012/12/25
独自型に書式を設定する [PS Advent Calendar '12]
本記事はPowerShell Advent Calendar 2012、最終日の記事です。
前回はAdd-Typeコマンドレットを使って独自のクラスを作成し、そのクラスを入力あるいは出力型に取る関数をどのように記述すれば良いのか、というお話でした。
今回は前回に残した課題である、ユーザー定義の独自型の出力にちゃんとした書式を設定する方法について説明していきます。
型データと書式設定データ
PowerShellは.NETオブジェクト（に限らず、型アダプタが存在するCOMやXMLなども、ですが…）をラッピングした型システムを有しているわけですが、このラッピング時にオブジェクトに対してPowerShell独自のデータを付与することができます。それが型データと書式設定データと呼ばれるものです。
型データはクラスにPowerShellエンジンが付加する独自のメンバ（プロパティ、メソッド）です。代表的なものにNoteProperty（静的な値をもつプロパティ）, ScriptProperty（スクリプトで記述されたgetterとsetterをもつプロパティ）, AliasProperty（既存プロパティのエイリアス）, CodeProperty（.NETのスタティックプロパティ）, CodeMethod（.NETのスタティックメソッド）, ScriptMethod（スクリプトで記述されたメソッド）があります。
型データは .types.ps1xmlファイルにその定義を記述し、モジュールならモジュールマニフェスト（.psd1）のTypesToProcessプロパティに型データファイルパスを指定することで、インポート時に型データを反映させることができます。
Update-TypeDataコマンドレットで後から型データファイルを読み込んで反映することもできます。PowerShell 3.0ではUpdate-TypeDataコマンドレットで.types.ps1xmlファイルを読むのではなく、直接任意のメンバを任意の型に追加することも可能になっています。
また、
$obj | Get-Member -View Extended
とすることで$objに追加されたメンバがどれなのかが分かります。（ちなみに型アダプタによって追加されたメンバはAdapted指定で分かります）
今回の記事では型データについてはこれくらいにして（またいつか改めて取り上げたいですが）、以下、本題の書式設定データの話をしていきます。
書式設定データとは
書式設定データも型データと同様、クラスに付加するデータなのですが、これはオブジェクトを出力する際のデフォルトの表示フォーマットを定義するものとなります。
たとえばGet-Processコマンドレットを実行すると
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
138 13 18456 7104 62 2052 aaHMSvc
88 8 2168 1268 55 2112 AdminService
...
のようにProcessオブジェクトが表形式で表示されます。
ここで表に含まれるプロパティ、IdとProcessNameは.NETのProcessクラスが持つオリジナルのプロパティで、HandlesはHandleCountプロパティのAliasPropertyです。NPMやWSなども対応するAliasPropertyやScriptPropertyが定義されているのですが、たとえばNPMというAliasPropertyはあってもNPM(K)というメンバはありません。これを定義しているのが書式設定データになるわけです。そもそもこの表に含まれるプロパティの種類であるとか、もっというとProcessオブジェクトは特に指定がない場合は表形式で表示する、といった定義も書式設定データに含まれます。
書式設定データも型データと同様にXMLファイルに定義されるのですが、その拡張子は.format.ps1xmlです。モジュールならマニフェストのFormatsToProcessプロパティに.format.ps1xmlファイルのパスを指定することで表示に反映されますし、Update-FormatDataコマンドレットによって後から反映させることも可能です。
この書式設定ファイルはユーザー定義型に関しても定義を記述できます。つまり、ユーザー定義型に対応する.format.ps1xmlファイルを記述し、それを読み込むことで、自分がAdd-Typeで作った型に対しても書式を設定できるわけです。次の節でそのやり方を見ていきましょう。
書式設定データの作り方
書式設定データ.format.ps1xmlの書式についてはMSDNにリファレンスがあるので、これを読めば自分で一から作成することは可能です。ですがそれはちょっと面倒くさいので、既存の書式設定データをベースに、独自型用に修正していくのがお勧めです。
書式設定データはGet-FormatDataコマンドレットで取得でき、Export-FormatDataコマンドレットでファイルとして出力できます。なお、Export-FormatDataコマンドレットの出力XMLファイルは改行コードが入っていなくて見づらいので、XmlDocumentとして再度読み込んでSave()するという小細工を施すのがお勧めです。先ほどのProcessクラス（System.Diagnostics.Process）の書式設定データをファイル化するには以下のようなスクリプトを実行します。
$ps1xml="process.format.ps1xml" Get-FormatData System.Diagnostics.Process | Export-FormatData -Path $ps1xml -IncludeScriptBlock ([xml](Get-Content $ps1xml)).Save((Join-Path (Get-Location) $ps1xml))
このスクリプトを実行すると、Processクラスの書式設定データをprocess.format.ps1xmlファイルとして出力できます。
出力した.format.ps1xmlはPowerShell ISE（ただしv3の）で開くのがお勧めです。ちゃんとXMLノードを折りたたみできるので。
さて、出力した.format.ps1xmlファイルをつらつらと眺めると、実際の出力書式の定義はビュー(View)という単位で行われていることがわかります。View要素の下にはName要素（ビューの名前）、ViewSelectedBy要素（ビューを反映する対象の型）、TableControl要素（表の書式）があります。
TableControl要素の下にはTableHeaders要素とTableRowEntries要素が含まれており、前者は表のヘッダーに記載するラベルやその幅などをTableColumnHeader要素に一つ一つ定義し、後者は表の本体に表示するオブジェクトのプロパティ値をTableColumnItem要素に一つ一つ定義しています。
TableColumnItem要素は単純にプロパティ値を表示させるならPropertyName要素にプロパティ名を書くだけでOKです。スクリプトの結果を表示させるならScriptBlock要素内にスクリプトを書きます。ScriptBlock要素内で自動変数$_に1オブジェクトが格納されています。
結局のところ、表に表示したいプロパティの分だけ、TableColumnHeader要素（プロパティ名のラベル）とTableColumnItem要素（プロパティ値）を1:1で定義していけばOKです。
以上を踏まえてprocess.format.ps1xmlを改変して、前回作成したWinscript.Driveクラスの書式設定ファイルdrive.format.ps1xmlを作成してみました。
<?xml version="1.0" encoding="utf-8"?>
<Configuration>
<ViewDefinitions>
<View>
<Name>drive</Name>
<ViewSelectedBy>
<TypeName>Winscript.Drive</TypeName>
</ViewSelectedBy>
<TableControl>
<TableHeaders>
<TableColumnHeader>
<Label>Name</Label>
<Width>4</Width>
</TableColumnHeader>
<TableColumnHeader>
<Label>VolumeName</Label>
<Width>15</Width>
</TableColumnHeader>
<TableColumnHeader>
<Label>Type</Label>
<Width>15</Width>
</TableColumnHeader>
<TableColumnHeader>
<Label>RootPath</Label>
</TableColumnHeader>
<TableColumnHeader>
<Label>Size(GB)</Label>
<Width>25</Width>
<Alignment>Right</Alignment>
</TableColumnHeader>
<TableColumnHeader>
<Label>Used(%)</Label>
<Width>7</Width>
<Alignment>Right</Alignment>
</TableColumnHeader>
</TableHeaders>
<TableRowEntries>
<TableRowEntry>
<TableColumnItems>
<TableColumnItem>
<PropertyName>Name</PropertyName>
</TableColumnItem>
<TableColumnItem>
<PropertyName>VolumeName</PropertyName>
</TableColumnItem>
<TableColumnItem>
<PropertyName>Type</PropertyName>
</TableColumnItem>
<TableColumnItem>
<PropertyName>RootPath</PropertyName>
</TableColumnItem>
<TableColumnItem>
<ScriptBlock>[int]($_.Size/1GB)</ScriptBlock>
<FormatString>{0:#,#}</FormatString>
</TableColumnItem>
<TableColumnItem>
<ScriptBlock>[int]($_.UsedSpace*100/$_.Size)</ScriptBlock>
</TableColumnItem>
</TableColumnItems>
</TableRowEntry>
</TableRowEntries>
</TableControl>
</View>
</ViewDefinitions>
</Configuration>
前回作成したスクリプトを実行後、このdrive.format.ps1xmlファイルを
Update-FormatData -AppendPath .\drive.format.ps1xml
のようにして現在のセッションに読み込んでやることで、以降は定義した関数を実行すると、
PS> Get-Drive Name VolumeName Type RootPath Size(GB) Used(%) ---- ---------- ---- -------- -------- ------- C: LocalDisk C:\ 112 88 D: LocalDisk D:\ 466 63 Q: CompactDisc Q:\ V: NetworkDrive \\server\D 1,397 64
このように定義した型のオブジェクトに対しても、綺麗な書式で出力することができるようになるわけです。
まとめ
ここまで全三回にわたって、「関数の定義」「型の定義」「出力書式の定義」の基本のきについて説明してきました。基本とはいえ、PowerShellでがっつりとちゃんとした関数を書く上で真っ先に押さえておかないといけないことばかりですし、逆にここまで必要最小限に絞った記事もあまりないかなと思い、まとめてみました。参考にしていただければ幸いです。
さて、PSアドベントカレンダー2012もこれで終わりです。皆様、よいクリスマス…はもう終わりなので、よいお年を！
※終わりと言っておきながら実は明日以降、ロスタイムとしてもうひとかたご登場の予定です。ご期待ください。
2011/12/02
バックグラウンドジョブの使い方・基本編 [PS Advent Calendar '11]
はじめに
このたび、技術系アドベントカレンダーイベントの1つとして、PowerShell Advent Calendar 2011を企画しました。この記事はその2日目の記事となります。アドベントカレンダーについてはリンク先を参照してください。
今日のテーマはPowerShellのバックグラウンドジョブ機能の使い方についてのまとめです。
バックグラウンドジョブとは
バックグラウンドジョブ機能はその名の通り、ジョブ（具体的にはスクリプト）をバックグラウンドで非同期に実行するものです。PowerShell v2で追加された機能の一つです。インタラクティブシェルでStart-Jobコマンドレットを使用してバックグラウンドジョブ（以下、単に「ジョブ」と表記）を実行すると、新しくpowershell.exeのプロセスが起動しそのままシェルに制御が戻りユーザーは後続の処理を行うことができます。もちろんスクリプトからジョブを実行することも可能です。時間のかかる処理をバックグラウンドで走らせたり、数多くの処理を並列で実行したりするのに重宝します。
起動されたジョブは操作中のpowershell.exeとは別のジョブ用のプロセスで実行され、処理が完了すると呼び出し元でその結果をReceive-Jobコマンドレットを使って受け取ることができます。ジョブは並列して何個も同時に実行できます。なおPowerShellのジョブは1ジョブ=1プロセスです。スレッドではないので注意。
PowerShellのジョブシステムはリモート処理インフラストラクチャの上に構築されているので、たとえローカルPCでもジョブ実行するにはローカルPCをリモート用構成にしておく必要があります。詳しくはabout_Remote_Requirementsを参照のこと。
ジョブはローカルでもリモートでも走らせることができます。以下に具体的な方法を述べていきます。
ローカルコンピュータでのジョブ実行
ローカルコンピュータ上に新しくジョブを作成して開始するにはStart-Jobコマンドレットを用います。
Start-Job {ジョブとして実行したいコマンド、スクリプト}
とするとジョブを実行します。
$job=Start-Job {..}
のようにするとJobオブジェクト（System.Management.Automation.PSRemotingJob）を変数に格納してあとで利用できます。変数で受けない場合はJobオブジェクトの内容が表示されます。
存在するジョブを取得するにはGet-Jobコマンドレットを用います。
Get-Job
で現在実行中のジョブ一覧を表示します。以下に出力例を示します。
Id Name State HasMoreData Location Command -- ---- ----- ----------- -------- ------- 1 Job1 Completed True localhost "test" 3 Job3 Running True localhost start-sleep -sec 120;"...
以下の表は各項目の意味です。
| Id | ジョブID番号 |
| Name | ジョブの名前 |
| State |
Running=実行中のジョブ Stopped=停止したジョブ Complete=完了したジョブ Failed=エラーが出たジョブ |
| HasMoreData | 返却されたデータがあるかどうか |
| Location | ジョブが実行されているコンピュータ名 |
| Command | ジョブで実行されているコマンド、スクリプト |
ジョブの終了を待つにはWait-Jobコマンドレットを用います。
Get-Job|Wait-Job
とすると実行中のジョブすべてが完了するまで待ちます。-timeoutパラメータを使うと最大待ち時間（秒）を指定できます。
Get-Job|Wait-Job -any
とすると実行中のいずれかのジョブが完了するまで待ちます。正確には「対象のジョブが一つ以上完了するまで待つ」という効果なので、完了済みのジョブが1つ以上ある場合に新たにジョブを追加した場合などは想定の動作になりません。あらかじめRemove-Jobで完了済みのジョブを削除するか、Where-ObjectコマンドレットでRunningのみ対象にするようフィルタをかけるかしてください。
ジョブを中止するにはStop-Jobコマンドレットを用います。
Get-Job -id 1|Stop-Job
とするとジョブIDが1のジョブを中止します。
$jobにJobオブジェクトが格納されている場合は
$job|Stop-Job
でもOKです。
ジョブを削除するにはRemove-Jobコマンドレットを用います。
Get-Job|where {$_.state -eq "Completed" -or $_.state -eq "Stopped"}|Remove-Job
とすると完了済みと中止したジョブを削除します。実行中のジョブは削除できませんが-forceパラメータを使って強制削除することは可能です。
ジョブの実行結果データを取得するにはReceive-Jobコマンドレットを用います。
Get-Job|Receive-Job
とすると完了済みのジョブのうち、結果を返却しているもの（HasMoreDataがTrueのジョブ）があればその結果を表示します。-keepパラメータをつければ結果データを保持しますが付けてない場合は参照後破棄します。
*-Job系のコマンドレットの多くはJobオブジェクトを返却するので、パイプラインでどんどん繋げていけます。
Get-Job|Wait-Job -timeout 10|Receive-Job
のように。
ジョブの基本的な使い方に関して詳しくはabout_jobsを参照してください。
イベントサブスクライブ
PowerShell 2.0では.NET Frameworkのオブジェクトのイベントをサブスクライブすることができます。すなわちイベントハンドラを記述することができます。このイベントサブスクライブ機能もジョブ機能を元に構築されています。
たとえばTimerオブジェクトのElapsedイベントをサブスクライブし、タイマーの実行間隔（ここでは1秒）ごとにtest.txtファイルに乱数を追記していくサンプルは次のようになります。
$timer=new-object System.Timers.Timer
$timer.Interval=1000
Register-ObjectEvent -EventName Elapsed -SourceIdentifier test -Action {get-random|add-content c:\users\daisuke\test.txt} -InputObject $timer
$timer.Enabled=$true
Register-ObjectEventの結果、新しくジョブが生成しそのJobオブジェクトが返却されます。このジョブは-EventNameパラメータで指定したイベントが発生するたび、-Actionパラメータで指定したスクリプトブロックを実行します。
なお、イベントサブスクライブを解除するには
Unregister-Event test
のように-SourceIdentifierパラメータで指定した値を指定してUnregister-Eventコマンドレットを実行することで可能です。サブスクライブを解除してもジョブ自体は削除されない（StateがStoppedになるだけ）ので、必要であればRemove-Jobで削除します。
なお.NETオブジェクトの他にPowerShellスクリプトのカスタムイベント（Register-EngineEvent）、WMIオブジェクトのイベント（Register-WmiEvent）をサブスクライブすることもできます。これらのコマンドレットも同様にイベント発生時の処理をジョブとして登録します。詳しくは各コマンドレットのヘルプを参照してください。
リモートコンピュータでのジョブ実行
最初に述べたとおりPowerShellのジョブ機能はリモートインフラストラクチャの上に構築されています。よってローカルのみならずリモートコンピュータに対してジョブを実行することができます。もちろんリモートコンピュータにもリモート構成されていることが条件です。
基本はInvoke-Commandコマンドレットを用い、
$job=Invoke-Command -ComputerName リモートコンピュータ名 {リモートで実行するコマンド、スクリプト} -asjob
となります。これで{}内の処理がリモートコンピュータ上のPowerShellインスタンスで実行されます。-asJobパラメータをつけることでジョブとして（ローカルPCから見て）非同期に処理できますが、-asJobパラメータを省略すると同期的に実行されます。この場合ジョブは作成されず、リモートでの処理が終了するまでローカル側は待機することになります。
リモートコンピュータに接続するための資格情報を別途入力する必要がある場合は-credentialパラメータを使用します。
Invoke-Command -ComputerName リモートコンピュータ名 {リモートで実行するコマンド、スクリプト} -asjob -credential ユーザー名
とするとパスワードを入力するダイアログが表示されます。なお、スクリプトで動かすときなどあらかじめ入力したパスワードを指定したい場合の方法は以前書きました。
同じコマンドを複数のリモートPCで同時実行することも可能で、その場合は-computerNameパラメータにリモートコンピュータ名の配列を指定します（「,」区切り）。この場合ローカルPCで見えるジョブとしては1つですが、そのジョブにリモートコンピュータの数だけ子ジョブ（ChildJobs）が作成されています。
このように子ジョブが複数ある場合にReceive-Jobするときは
$job|Receive-Job -location リモートコンピュータ名
あるいは
$job.ChildJobs
として表示される子ジョブの名前(Name)を調べ、
Receive-Job -name 子ジョブの名前
とすることでリモートコンピュータごとに結果を取得できます。
すべての結果をまとめて取得するなら
Receive-Job $job
とします。
$job|Receive-Jobはなぜか駄目なようです。
固定セッションを用いたリモーティング
同じリモートPCに対して何度もコマンドを実行させたい場合、毎回リモートコンピュータ名を指定してセッションを張るのは非効率的なので、リモートセッションを確立したあとその固定セッションを何度も使用する方法が用意されています。新しく固定セッションを確立するにはNew-PSSessionコマンドレットを用い、
$session=New-PSSession リモートコンピュータ名
とすると固定セッションが確立され、$session変数にそのセッションオブジェクトが格納されます。あとは
Invoke-Command $session {リモートで実行するコマンド、スクリプト} -asjob
とすればそのたびにそのセッションを用いてリモートでコマンドを実行できるようになります。
ここまでの説明はリモートコンピュータでしてきましたが、ローカルコンピュータに対して固定セッションを張ることも可能です。
さらに、Enter-PSSessionコマンドレットを用いると作成したセッションに入ってリモートコンピュータ上のPowerShellを対話実行することも可能です。
Enter-PSSession $session
とすると、プロンプトが
PS カレントディレクトリ>
から
[リモートコンピュータ名]: PS カレントディレクトリ>
に変化し、以降リモートのPowerShellをローカルPCから対話実行できます。
なおこの状態から抜けるにはexitもしくはExit-PSSessionと入力して実行します。
ジョブ実行できるそのほかのコマンドレット
これまで述べたコマンドレット以外にも、いくつかのコマンドレットはジョブ実行（ローカルorリモート）することができます。ジョブ実行するには-asJobパラメータを使用します。以下にv2の段階で-asJobパラメータが定義されているそのほかのコマンドレットを示します。
- Get-WmiObject
- Invoke-WmiMethod
- Remove-WmiObject
- Set-WmiInstance
- Test-Connection
- Restart-Computer
- Stop-Computer
これらのコマンドレットはコマンドレット自体にジョブ実行機能がついているので、単独で実行するだけならStart-JobやInvoke-Commandを用いる必要がありません。v2ではWMIを扱うコマンドレットにのみ-asJobパラメータが存在するようです（ここに挙げたコマンドレットはすべてWMIの機能を呼び出すもの）。なお、-asJobパラメータが使用できるコマンドレットの一覧を取得するのに、fsugiyamaさんの1日目の記事の問15のスクリプトを使用させていただきました。
おわりに
PowerShell Advent Calendar 2011二日目は、PowerShellのバックグラウンドジョブ機能概要についてまとめてみました。実はバックグランドジョブ機能のTipsを書こうと思ってその前ふりとして書き始めたのですが、これだけでかなりの量になってしまったので概要だけ一記事としてまとめることにしました。おそらくPSアドベントカレンダーに私はあと何回か登場することになりそうですので、Tips編はその際に書こうと思います。
さて、明日三日目は@jsakamotoさんのご登場ですね。よろしくお願いします！
そして参加者はまだまだ募集中ですよ！→PowerShell Advent Calendar 2011
Copyright © 2005-2016 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
