Windows PowerShell: スクリプトを簡単に共有できるようになりました

[アーティクル]
08/25/2016

Don Jones

Windows PowerShell 1.0 では、スクリプトの共有が簡略化されなかったという欠点がありました。確かに、.ps1 スクリプトファイルを別のコンピューターにコピーしたり、圧縮してメールに添付して同僚に送信することはできました。ですが、このような操作は、10 年以上も前から VBScript でも行えました。ただし、スクリプトに再利用可能な関数が含まれていても、スクリプトを受け取った人が、ドットソース形式でスクリプトを使用する方法を把握している必要があり、この方法を知らない場合は、再利用可能な関数を実行するために、スクリプトを編集しなければなりませんでした。

全体的に見て、このような運用方法は、理想的ではないにしても、許容されていました。ですが、このような追加ファイルをスクリプトで使用するには手動でシェルに読み込む必要があるため、独自の書式設定のビューや拡張子を使用するスクリプトは、徐々に許容されなくなりました。

ですが、Windows PowerShell 2.0 では、モジュールの導入により、理想に近い状態を実現しました。

シェルの良いところを寄せ集めた自己解決型のスクリプト

モジュールは、相互に関連のある一連のファイルで、大まかに分類すると、バイナリとスクリプトの 2 種類に分けられます。

バイナリモジュールは、1 つ以上の DLL ファイルで構成されており、DLL ファイルは、C# や Visual Basic などの Microsoft .NET Framework 言語でコンパイルされています。Windows PowerShell 1.0 では、モジュールを PSSnapin と呼んでおり、Visual Studio で記述するという点については同じでした。ただし、PSSnapin では、DLL をシェルに登録するためのインストーラーを記述する必要がありました。モジュールの場合はインストールする必要がなく、代わりに .psd1 ファイル (モジュールマニフェスト) が付属しています。モジュールマニフェストは、読み込む必要がある DLL を示す単なる XML データです。また、マニフェストファイルでは、付属する拡張子ファイル (.ps1xml) とビューファイル (.format.ps1xml) を指定することもできます。

しくみは次のとおりです。モジュールは、Windows PowerShell の \modules フォルダーのサブディレクトリにインストールする必要があります。既定では、このディレクトリは c:\windows\system32\windowspowershell\v1.0\modules にあります。つまり、MyModule という名前のモジュールは、c:\windows\system32\windowspowershell\v1.0\modules\mymodule にインストールし、マニフェストファイルは、mymodule.psd1 という名前になります。このモジュールに関連のあるファイルは、同じフォルダーに配置され、スクリプトが自己解決型になるようになっています。

このモジュールを読み込むには、Import-Module MyModule というコマンドを実行します。シェルは、既定で \modules フォルダーを検索し、.psd1 ファイルを検出すると、ファイルを読み取って、参照されているファイルを読み込みます (別の場所にモジュールをインストールしている場合は、Import-Module コマンドレットで完全パスを指定します)。モジュールは簡単に配布することが可能で、必要な作業は、すべてのファイルを圧縮して、.zip ファイルを別のコンピューターにコピーするだけです。インストールの必要はありません。

自作のモジュールを展開する

今度は、スクリプトを簡単に配布できるしくみについて説明しましょう。それには、もう 1 つのモジュールの種類であるスクリプトモジュールを使用します。スクリプトモジュールは、通常の Windows PowerShell スクリプトですが、拡張子は、通常の .ps1 ではなく .psm1 となります。mymodule.psm1 を \modules フォルダーに配置すると、Import-Module MyModule というコマンドを使用して、スクリプトを実行できます。

通常、スクリプトモジュールは、関数で構成されています。つまり、モジュールをインポートしても、何も実行されません。スクリプトモジュールに含まれる関数がシェルに読み込まれ、そのシェルで使用できるようになるだけです。次のようなスクリプトモジュールがあるとしましょう。

Function Get-Inventory {
 # (some code goes here)
}
Function Test-Connectivity {
 # (some code goes here)
}
Function Write-Inventory {
 # (some code goes here)
}

このモジュールをインポートすると、シェルでは、コマンドと同じような感覚で、Get-Inventory 関数、Test-Connectivity 関数、および Write-Inventory 関数を使用できるようになります (来月は、コマンドレットとほぼ同じように動作する関数を記述する方法を紹介します)。関数にはコメントベースのヘルプ情報を含めることができるので、このモジュールをインポートして、Help Get-Inventory というコマンドを実行すると、この関数を使用するのに必要な情報が表示されます (コメントベースのヘルプ情報については、先月のコラムで取り上げました)。

プライバシーが必要な場合はどうするのか

複雑なスクリプトモジュールには、他の関数でのみ使用することを想定し、ユーザーによって使用されることを想定していない関数が含まれていることがあります。たとえば、Test-Connectivity 関数と Wirte-Inventory 関数は、このモジュールでのみ使用することを想定しているとしましょう。つまり、これらの関数は Get-Inventory 関数で呼び出され、シェルのユーザーから直接呼び出されることは想定していない場合です。

既定では、Import-Module コマンドレットでは、モジュールに含まれるすべてのものを読み込んで、シェルユーザーが、すべての関数を参照できるようにします。この動作は、ユーザーに表示する関数の一覧を指定することで無効にできます。この一覧に含まれない関数は、シェルユーザーに表示されません。この動作を実現するのに必要な処理は、次のようにスクリプトモジュールの最後で Export-ModuleMember コマンドレットを実行するだけです。

Export-ModuleMember –function Get-Inventory

必要に応じて、スクリプトで定義しているコマンドレット、変数、およびエイリアスもエクスポートできます。詳細については、Help Export-ModuleMember というコマンドを実行するか「Export-ModuleMember」を参照してください。

モジュールの欠点

個人的に感じている Windows PowerShell 2.0 で導入されたモジュールの唯一の欠点は、シェルの既定の場所が 1 つしかなく、その場所が Windows システムフォルダーにあることです。このような場所にあるスクリプトを変更する癖が付くのは望ましくありません。ですが、PSModulePath 環境変数について調べたところ、シェルではドキュメントフォルダーも検索されることがわかりました。具体的には、WindowsPowerShell\Modules というサブフォルダーです。私が記述したモジュールは、この場所に配置しています。

今後は、インターネットベースのリポジトリから追加のモジュールをダウンロードするように設計されたコマンドレットが登場するでしょう (Unix システムの Pear 機能では、このようなことはできません)。このようなコマンドレットは、ドキュメントフォルダーか OS とは別の場所にダウンロードされる可能性が高いので、既定でシェルがドキュメントフォルダーを検索するように設定することをお勧めします。

どこもかしこもモジュールだらけ

インストールしなくてもシェルで認識されるので、モジュールの使用頻度は高まっています。実際、Windows Server 2008 R2 に同梱されている Windows PowerShell 拡張機能のほとんどはモジュール形式でパッケージ化されています。ただし、Windows Server バックアップを自動化する機能だけは PSSnapin 形式になっています (この PSSnapin がサーバーにインストールされているかどうかについては、Get-PSSnapin -registered というコマンドを実行して確認ください)。サードバーティが記述したコードもモジュール形式で配布されるものが増えています。たとえば、PoshCode.org (英語) のコミュニティコードリポジトリにアクセスするコマンドレットが、その一例です。

筋金入りの Windows PowerShell のユーザーで、独自のコマンドレットを記述するのに興味はあるものの、Visual Studio で .NET Framework のプログラミングに着手したくないと考えている方は、高度な関数とモジュールを組み合わせると、スクリプトだけで、独自のシェルスナップインを記述できます (高度な関数については、先ほどもお伝えしたとおり、来月のコラムで取り上げます)。コマンドレットと同じような外観と動作を備えた高度な関数をスクリプトモジュールにパッケージ化するだけで、再利用可能なコードを簡単に配布できるようになります。

Windows PowerShell 2.0 提供開始

Windows PowerShell 2.0 は Management Framework コンポーネントと共に Windows Server 2008 R2 および Windows 7 に同梱されていましたが、Windows XP、Windows Server 2003、Windows Vista、および Windows Server 2008 でも利用できるようになりました。support.microsoft.com/kb/968929 (英語) にアクセスして、ご使用の OS のダウンロードリンクからダウンロードできます。ほとんどの場合、Windows PowerShell 2.0 は、お手持ちの Windows PowerShell 1.0 のスクリプトと互換性があります。今後のコラムは、皆さんが Windows PowerShell 2.0 を使用している前提で執筆します。

Don Jones は、Concentrated Technology の創設者で、www.ConcentratedTech.com (英語) で Windows PowerShell や他のテクノロジに関する質問に答えています。また、Nexus.Realtimepublishers.com (英語) の創設者でもあり、このサイトでは、彼の多くの著書が無料でオンラインブックとして提供されています。