実は明日、植林ボランティアへ出発します。

行き先はタイで8/2に帰国します。

その準備もあって最近更新できていなかったのですが、おそらく帰国するまで更新ができません。

楽しみにしていただいている方にはご迷惑おかけしますがご了承願います。

HIRO

前回はステップ実行について説明しました。

今回はブレークポイントを設定する方法について紹介します。

ブレークポイントの設定は、以外と簡単で $host.EnterNestedPrompt() をブレークポイントをかけたい場所に記述するだけです。

以前に紹介したスクリプトにブレークポイントを設定して実験してみたいと思います。(5行目に挿入しました。スクリプトはC:\Work\Debug.ps1として保存します）

$a = 2
$b = 3
$c = $a + $b
$host.EnterNestedPrompt()   #ブレークポイントの設定
Write-Debug "Line4: $c"
$a = 4
$b = 5
$c = $a + $b
Write-Debug "Line8: $c"

上記を実行してみます。

PS C:\Work> ./Debug.ps1
デバッグ: Line4: 5
PS C:\Work>>>

上記のように、ブレークポイントを設定した位置までコードが実行されプロンプトが表示されたと思います。

この状態は、前回のステップ実行で説明した「中断処理」と同様で、変数の状態を確認することが可能です。

試しに $a, $b, $c がどうなっているかみてみましょう。

PS C:\Work> ./Debug.ps1
デバッグ: Line4: 5
PS C:\Work>>> $a
2
PS C:\Work>>> $b
3
PS C:\Work>>> $c
5
PS C:\Work>>>

変数の値を確認できました。プロンプトを終了するには exitと入力して[Enter]キーを押します。

PS C:\Work>>> exit
デバッグ: Line8: 9
PS C:\Work>

ブレークポイントを設定するのが簡単だということをおわかりいただけたでしょうか？

是非使ってみてください。

Set-PSDebug コマンドレットの-Stepパラメータを使用すると、ステップ実行を行うことができます。

以前にも使用したことのある下記スクリプトで実験してみましょう。

下記スクリプトをメモ帳などで入力してC:\Work\Debug.ps1 に保存します。

$a = 2
$b = 3
$c = $a + $b
Write-Debug "Line4: $c"
$a = 4
$b = 5
$c = $a + $b
Write-Debug "Line8: $c"

以下の一文を入力し[Enter]を押すとステップ実行が開始されます。

PS C:\Work> Set-PSDebug -step; ./Debug.ps1

1行実行されるごとにメッセージが表示されます。

PS C:\Work> Set-PSDebug -step; ./Debug.ps1

この操作を続行しますか?
   1+ Set-PSDebug -step; ./Debug.ps1
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):
デバッグ:    1+ Set-PSDebug -step; ./Debug.ps1

「規定は"Y"」と憑依されている箇所がありますが、これは[Enter]キーを押すと次の行が押される、つまり[Y]キーを押すのと同じ操作を行うこと意味します。

とりあえず[Enter]を押していって、下記のような状態になったらいったん止まってください。

PS C:\Work> Set-PSDebug -step; ./Debug.ps1

この操作を続行しますか?
   1+ Set-PSDebug -step; ./Debug.ps1
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):
デバッグ:    1+ Set-PSDebug -step; ./Debug.ps1

この操作を続行しますか?
   1+ $a = 2
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):
デバッグ:    1+ $a = 2

この操作を続行しますか?
   2+ $b = 3
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
(既定値は "Y"):

この状態で下記のように「中断」を意味する[S]キーを入力してみましょう。

この操作を続行しますか?
  2+ $b = 3
Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ
既定値は "Y"):S

[S]を入力すると、下記のように PS C:\Work>>>　というプロンプトが表示されたと思います。ここで $a[Enter] と入力してみてください。

PS C:\Work>>> $a
2

2という値が表示されたと思います。このように処理を中断して変数の中身を確認することが可能です。

プロンプトを終了するには exit と入力します。

Visual Studio.NETのように現在ステップ実行している行がハイライトされるわけではないので見にくく感じるかもしれませんが、慣れてしまえば非常に有効なデバッグ手段です。

是非ためしてみることをおすすめします。

Set-PSDebugコマンドレットによるデバッグ(PowerShell 入門) でSet-PSDebugコマンドレットの使用方法について説明しました。

今回は、このコマンドレットの-Strictパラメータを使用して、未定義の変数をエラーとして扱ってみましょう。

下記スクリプトで実験してみたいと思います。

ファイル名 Strict.ps1 とし C:\Work に保存したものとします。

1 * $a

上記スクリプトの中の$aはどこでも定義されていない状態で、いきなり使用されています。

これをSet-PSDebugコマンドレットで-Strictパラメータを使用して実行してみましょう。

PS C:\Work> Set-PSDebug -Strict; ./Strict.ps1
変数 $a は、設定されていないために取得できません。
発生場所 C:\Work\Strict.ps1:1 文字:7
+ 1 * $a <<<<

このように-Strictパラメータを使用すると、未定義の変数があることがわかります。

では、先ほどのスクリプトを修正して、変数$aを定義された状態で実験してみましょう。

修正したStrict.ps1

$a = 3
1 * $a

修正したスクリプトを再度デバッグしてみます。

PS C:\Work> Set-PSDebug -Strict; ./Strict.ps1
3

未定義の変数がない場合には、エラーにならずに処理が行われることが確認できます。

未定義の変数を見つけたい場合には是非 -Strict パラメータを使用してみてください。

自分が管理している、PowerShell from Japan!! はBlogEngine.NETを使用しています。

この、BlogEngine.NETでは複数のAuthorが１つのブログを書き上げることができます。（これがBlogEngine.NETを採用した一番の理由です）

現在、バージョン1.4を使用していますが、新規で作成したユーザーはログインできないという不具合があるようです。

いろいろ調べた結果、ログイン時のパスワードチェックに問題があるようです。

ユーザー情報はユーザーID,パスワード（暗号化される）などXMLファイルに保存されます。(SQL Serverを使用しない場合）

そして、ログイン時に、このXMLに格納されているパスワードと、入力されたパスワードとを比較するのですが、

XMLから読み込んだHash化されていないパスワードと入力されたパスワードをHash化したもの

とを比較するためにログインできないようです。どちらもHash化されたもので比較すれば問題ないのでしょうけど...

この部分はBlogEngine.Core\Providers\XmlProviders\XmlMembersshipProvider.cs の CheckPasswordメソッドで行われています。

パッチが待てない方は、この辺をいじってみることをおすすめします。

私はスタートアップにPowerShellを登録しており、いつでも使えるようにしています。

最近では電卓として使用することが多いです。

四則演算子以外にも下記のような.NET Frameworkの数学関数が使用できるので、重宝します。

PowerShellを電卓として使用するメリットとして、

• 計算のために入力した式をかくにんできる
• 履歴機能を使用して、再計算できる　&　この機能を利用して一部だけを変えて再度計算も可能
• よく使う計算式はスクリプト化して再利用可能

などがあげられます。

短所は、Windowsに付属の電卓と違ってSinとかも「ボタン一発」ではなく一文字一文字入力しなければ行けないことでしょうか？

Mathクラスの使用方法ですが、

PS C:\Work> [Math]::Sqrt(4)
2
PS C:\Work> [Math]::Pow(2,5)
32

のように [Math]::メソッド と記述します。

ぜひ電卓としても使用してみてください。慣れると重宝すること間違いなしです。

PowerShellには、スクリプトのデバッグを行うために、Set-PSDebugというコマンドレットがあります。

書式は大きく2つに分けることができ

Set-PSDebug [-Trace 数値] [-Step] [-Strict]

Set-PSDebug -Off

です。[]がついている箇所は省略可能です。

-Traceパラメータ

-Traceパラメータに指定できる値には下記の3つがあります。

では、前回のスクリプトファイル(Debug.ps1)を使用して実験してみましょう。

$a = 2
$b = 3
$c = $a + $b
Write-Debug "Line4: $c"
$a = 4
$b = 5
$c = $a + $b
Write-Debug "Line8: $c"

-Traceに0を指定した場合

まずはSet-PSDebugコマンドレットによるスクリプトファイルのデバッグ方法ですが

Set-PSDebug -trace 0; ./Debug.ps1

のようにします。

-Traceパラメータに0を指定した場合の実行結果は下記の通りで、値0はトレースが無効となっているために1行だけ表示して終わっています。

デバッグ出力の行には、先頭に「デバッグ：」と表示さ異なる色で表されていることに注意してください。

PS C:\Work> Set-PSDebug -trace 0; ./Debug.ps1
デバッグ:    1+ Set-PSDebug -trace 0; ./Debug.ps1

-Traceに1を指定した場合は行トレースとなりますので、すべての行がデバッグ表示されます。

-Traceに1を指定した場合

PS C:\Work> Set-PSDebug -trace 1; ./Debug.ps1
デバッグ:    1+ Set-PSDebug -trace 1; ./Debug.ps1
デバッグ:    1+ $a = 2
デバッグ:    2+ $b = 3
デバッグ:    3+ $c = $a + $b
デバッグ:    4+ Write-Debug "Line4: $c"
デバッグ:    5+ $a = 4
デバッグ:    6+ $b = 5
デバッグ:    7+ $c = $a + $b
デバッグ:    8+ Write-Debug "Line8: $c"

-Traceに2を指定した場合

-Traceに2を指定した場合は変数の代入、関数呼び出しなど、各行で行われている詳細情報を見ることができます。

PS C:\Work> Set-PSDebug -trace 2; ./Debug.ps1
デバッグ:    1+ Set-PSDebug -trace 2; ./Debug.ps1
デバッグ:     ! CALL script 'Debug.ps1'
デバッグ:    1+ $a = 2
デバッグ:     ! SET $a = '2'.
デバッグ:    2+ $b = 3
デバッグ:     ! SET $b = '3'.
デバッグ:    3+ $c = $a + $b
デバッグ:     ! SET $c = '5'.
デバッグ:    4+ Write-Debug "Line4: $c"
デバッグ:    5+ $a = 4
デバッグ:     ! SET $a = '4'.
デバッグ:    6+ $b = 5
デバッグ:     ! SET $b = '5'.
デバッグ:    7+ $c = $a + $b
デバッグ:     ! SET $c = '9'.
デバッグ:    8+ Write-Debug "Line8: $c"

上記を見るとわかるように、一番最初に関数呼び出しを行っているので

! CALL script 'Debug.ps1'

と表示されています。

また、変数に値がセットされるときは

SET $a = '2'.

のように表示されていることがわかります。

上記をまとめると

-Traceは、どの行を通って来たかを確認するだけであれば"1"を、詳細情報（変数にセットされた情報、関数呼び出しなど）を得たい場合には"2"を指定すれば良いことがわかります。

うまく使い分けて、デバッグに活用してみてください。

スクリプトを開発し始めると、途中経過を確認しながら開発を進めたいと思うときはありませんか？

このようなときに使用するコマンドレットがWrite-Debugコマンドレットです。

このコマンドレットは、コンソールウィンドウにメッセージを表示するためのコマンドレットです。

コンソールにメッセージを表示するコマンドレットとしてはWrite-Hostコマンドレットがありますが、両者にはどのような違いがあるでしょう？

それは、

• Write-Hostコマンドレットは、実行すれば必ず表示を行う。
• Write-Debugコマンドレットは、$DebugPrefeenceによって表示制御が行われる

という違いがあります。

$DebugPreferenceは下記の３つの値を指定することが可能です。

それでは、下記スクリプト(Debug.ps1とします）を準備して、それぞれについて実験をしてみましょう。

$a = 2
$b = 3
$c = $a + $b
Write-Debug "Line4: $c"
$a = 4
$b = 5
$c = $a + $b
Write-Debug "Line8: $c"

Continue

まずは、下記のようにして $DebugPreferenceの設定を変更します。

PS C:\Work> $DebugPreference = "Continue"

つぎに、作成したスクリプトを実行してみましょう。

PS C:\Work> ./Debug.ps1
デバッグ: Line4: 5
デバッグ: Line8: 9

Write-Debugに指定したメッセージがきちんと表示されていますね。

SilentContinue

まずは、下記のようにして $DebugPreferenceの設定を変更します。

PS C:\Work> $DebugPreference = "SilentlyContinue"

スクリプトを実行します。

PS C:\Work> ./Debug.ps1
PS C:\Work>

Stop

まずは、下記のようにして $DebugPreferenceの設定を変更します。

PS C:\Work> $DebugPreference = "Stop"

スクリプトを実行します。

PS C:\Work> ./Debug.ps1
デバッグ: Line4: 5
Write-Debug : シェル変数 "DebugPreference" が Stop に設定されているため、コマンドの実行が停止されました
発生場所 C:\Work\Debug.ps1:4 文字:12
+ Write-Debug  <<<< "Line4: $c"

1つめのWrite-Debugで指定されたメッセージを表示した後、エラーメッセージを表示して処理を中断したことがわかります。

Inquire

まずは、下記のようにして $DebugPreferenceの設定を変更します。

PS C:\Work> $DebugPreference = "Inquire"

スクリプトを実行します。

PS C:\Work> ./Debug.ps1
デバッグ: Line4: 5

確認
この操作を続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [H] コマンドの中止(H)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):

1つめのWrite-Debugで指定されたメッセージを表示したあとに、スクリプトを実行するかを確認してくることがわかります。

ここで[Y]または[A]を押すと、スクリプトが続行されます。

確認
この操作を続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [H] コマンドの中止(H)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):
デバッグ: Line8: 9

確認
この操作を続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [H] コマンドの中止(H)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):

このように、Write-Debugコマンドレットを使用すれば、デバッグ時のみメッセージを表示すしそれ以外は表示しない、という制御を行うことができますので、是非活用してみてください。

Vimの入手、インストール、PowerShellからの使用について説明したいと思います。

入手

日本語版VimはKaoriYa.netさんのところから 入手可能です。

現時点で最新版は7.1のようです。 

インストール

 Ver.7.1で説明します。

vim71-20080531-kaoriya-w32j.exe をダウンロードしてきたら ダブルクリックして解凍します。

vim71-kaoriya-w32j　というフォルダが作成されその中にファイルができあがります。

このフォルダをリネーム(vim71としました)して好きな場所に移動してください。(C:\Program Files\vim71 へ移動したものとします)

起動

PowerShellから起動できるようにするための前準備をしましょう。

まずはプロファイルを開いて、下記の1行を追加します。

Set-Alias vim 'C:\Program Files\vim71\vim.exe'

プロファイルの場所は、コマンドラインで$Profileと入力することで確認できます。　存在しない場合は新規で作成してください。

プロファイルへの書き込みが完了したら、PowerShellを再起動し、コマンドラインで

PS　> vim

と入力します。するとPowerShell上でvimエディタを使用することができるようになります。

皆さんはPowerShellのスクリプト開発に、どのエディタを使用していますか？

PowerShellのスクリプトはテキストベースなので、メモ帳さえあれば作成することが可能です。

世の中にエディタはたくさんありますが、その中でも Power GUIは　PowerShell専用のエディタが含まれています。

残念ながら日本語版はないのですが、あまり迷わずに使うことができると思います。

入手先は、http://www.powergui.org/downloads.jspa です。

特徴としては、

• コマンドレットや関数など色分け表示できる
• VB.NETやC#のようにregionでくくることができる
• インテリセンスによるコード補完
•  ステップ実行

などなど、スクリプト開発に欠かせない機能が盛りだくさんです。

詳細について、後日紹介していきたいと思います。

もう１つ紹介したいのがVimです。

UNIXユーザーとかにはおなじみのViですが、日本語Windows対応のVimが存在します。

KaoriYa.netさんのところから入手可能です。

これについてもあとで紹介したいと思います。

これ以外で、PowerShellの開発に使用しているエディタがありましたら、ぜひ情報をお寄せください。

今日、会社のメンバーからDataGridViewに「ボタン列を追加したいんだけど」と相談を受けました。

「HIRO's.NETにやり方載ってないね」との突っ込みが... 確かにその通り載っていません。

実際には、下記のようなやり方で実現できます。

DataGridViewButtonColumnインスタンス（これがボタン列になります）を作成して、DataGridViewに追加すればOKです。

ボタンがクリックされると、CellContentClickイベントが発生するので、引数e（DataGridViewCellEventArgs）のe.RowIndexやe.ColumnIndexを調べればどのボタンが押されたかがわかります。

実行例は下図のような感じです。

コードは下記の通りです。

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    AddButton()
End Sub

Private Sub AddButton()
    Dim dtSet As New DataSet()
    dtSet.ReadXml("C:\Work\Test.xml")
    DataGridView1.DataSource = dtSet.Tables(0)

    'DataGridViewButtonColumnを作成する
    Dim colBtn As New DataGridViewButtonColumn()

    '列名とボタン名を設定
    colBtn.Name = "ボタン列"
    colBtn.Text = "ボタンです"

    '所有側の列のテキストを、セル内のボタンに表示
    colBtn.UseColumnTextForButtonValue = True


    'DataGridViewに追加する
    DataGridView1.Columns.Add(colBtn)
End Sub

Private Sub DataGridView1_CellContentClick(ByVal sender As System.Object, _
    ByVal e As System.Windows.Forms.DataGridViewCellEventArgs) Handles DataGridView1.CellContentClick

    If DirectCast(sender, DataGridView).Columns(e.ColumnIndex).Name = "ボタン列" Then
        MessageBox.Show((e.RowIndex + 1).ToString() & "のボタンが押された")
    End If
End Sub

前回、trap文をスクリプトファイルの先頭に記述しましたが、これをスクリプトファイルの後半に記述したらどうなるかを実験しました。

break文での実験

1/$Null

Write-Host "スクリプト終了"

trap 
{
    "例外が発生しました"
    break
}

上記を実行した結果は下記の通りです。前回同様、例外をきちんとトラップして処理を中断することがわかります。

PS C:\Work> ./trap1.ps1
例外が発生しました
0 で除算しようとしました。
発生場所 C:\Work\trap1.ps1:1 文字:3
+ 1/$ <<<< Null

continue文での実験

1/$Null

Write-Host "スクリプト終了"

trap 
{
    "例外が発生しました"
    continue
}

上記を実行した結果は下記の通りです。こちらも前回同様、例外をきちんとトラップして処理を中断することがわかります。

PS C:\Work> C:\Work\trap2.ps1
例外が発生しました
スクリプト終了

このようにtrapを使用した例外処理はスクリプトファイルのどこにおいても有効です。

私個人としては、今回のようにスクリプトファイルの後半（例外が発生しそうなポイントの直後）へ配置するほうが好きです。

PowerShellではTrap文を用いることで、例外処理を行うことができます。

trap文の構文は下記の通りです。

trap [<例外の種類>]
{
    trap文本体
}

「例外の種類」は省略することが可能です。

たとえば下記は、1/$Null　を実行すると、ゼロ除算例外が発生するため、trapへ制御が移り "例外発生" の文字列を表示します。

PS C:\Work> trap
>> {"例外発生" }
>> 1/$Null
>>
例外発生
0 で除算しようとしました。
発生場所 行:3 文字:3
+ 1/$ <<<< Null

実際にスクリプトで使用する例を見ていきたいと思います。

まずはtrapなしの下記をメモ帳などで入力し、trap1.ps1 として保存してください。

1/$Null

Write-Host "スクリプト終了"

このスクリプトを実行すると下記のようにエラーメッセージが表示された後、「スクリプト終了」という文字が表示されます。

PS C:\Work> ./trap1.ps1
0 で除算しようとしました。
発生場所 C:\Work\trap1.ps1:1 文字:3
+ 1/$ <<<< Null
スクリプト終了

breakで処理を中断する

次に、例外を捕らえて処理を中断してみましょう。中断するにはbreakを使用します。(trap2.ps1)

trap 
{
    "例外が発生しました"
    break
}

1/$Null

Write-Host "スクリプト終了"

このスクリプトを実行すると下記のように、例外が発生するとTrapを実行するので「例外が発生しました」のメッセージとエラーメッセージを表示し、処理を中断します。

この結果、「スクリプト終了」の文字列は表示されません。

PS C:\Work> ./trap2.ps1
例外が発生しました
0 で除算しようとしました。
発生場所 C:\Work\trap.ps1:7 文字:3
+ 1/$ <<<< Null

continueを使用する

次にtrapの中でcontinueを使用するとどうなるかみてみましょう。(trap3.ps1)

trap 
{
    "例外が発生しました"
    continue
}

1/$Null

Write-Host "スクリプト終了"

実行結果は下記の通りで、例外が発生すると「例外が発生しました」のメッセージが表示され、最後の「スクリプト終了」が表示されます。

PS C:\Work> ./trap3.ps1
例外が発生しました
スクリプト終了

このようにcontinueを使用した場合はエラーメッセージは表示されず、trapを実行後、例外が発生した次の行から処理が再開されます。

HIRO's.NETプロジェクトの一つとしてPowerShell from Japan!! という新サイトを立ち上げました。

「日本でPowerShellの情報を得るならここ！！」というサイトを目指しています。

PowerShell from Japan!!のメンバーになられた方たちが、ブログ形式で、PowerShellのネタを綴っていく予定です。

現在メンバー募集中で（現時点で3名の方がメンバーとなっています）、PowerShellネタを書いてみたい方であれば誰でも参加OKです。

また、これに伴いPowerShell専用 Wikiも立ち上げました。こちらはWikiですがPowerShell from Japan!!メンバーの方に編集を行っていただくことにしています。

メンバーになりたい方、こちらよりご連絡ください。

HIRO's.NETのサイト共々、応援よろしくお願いいたします。

HIRO

9/13（土）にtechbank.jp、Visual Basic中学校、とっちゃん、そしてHIRO's.NETでの合同勉強会が決定いたしました。

後援： INETA Japan(予定), Culminis(予定) 
日時：  2008/09/13 （土） 13:00～17:30 
場所：  マイクロソフト新宿本社（OST）５FセミナールームA＆B
アクセス方法: ・JR / 都営線 / 各東京メトロ新宿駅より徒歩 1～3 分
・東京メトロ小田急線南新宿駅より徒歩 2 分
・東京メトロ丸ノ内線新宿三丁目駅より徒歩 9 分

です。

当日は

■ 13:00～13:20 ： オープニング
（会場の説明とご案内、後援団体とスポンサー紹介、セッション概要）
■ 13:30～14:10 ： GDI+とVisual Basic ：
    想定レベル：レベル100？
    るきお (「Visual Basic 中学校」 管理人, Microsoft MVP for Visual Basic）：
■ 14:20～15:10 ： PowerShell入門 ： 
    想定レベル：レベル100
    HIRO（「HIRO's.NET 管理人」）： 
■ 15:20～16:10 : インストーラー関係（お題未定）： 
    想定レベル：レベル200？
    とっちゃん ( Microsoft MVP for Visual C++ )： 
■ 16:20～17:10 :
　　レスポンスを改善しよう！「パフォーマンスチューニング」術 ～ ASP.NET + SQL Server編～ : 
    想定レベル：300
    けろ-みお (「techbank.jp」管理人、Microsoft MVP for ASP/ASP.NET ) ： 
■17:10 ～ 17:15 ： エンディング
■18:30 ～ 20:00 ： 懇親会（参加希望者のみ)

を予定しております。

MVPの方々に混じって話すのは恐縮なのですが（私以外MVPの方です。なので来る価値ありですよw）、PowerShellの入門についてお話しさせていただきたいと思っています。

有名なサイトの管理人さん多数参加予定です。懇親会も予定されております。

ぜひたくさんの方の、ご参加お待ちしております。

参加登録は、上記のバナーからどうぞ！！

以前 2>&1　演算子 を使用することでエラーの内容を変数に代入できることを説明しました。（エラーをファイルにリダイレクトする(PowerShell 入門)）

この演算子を使用する以外に、各コマンドレットで共通に使用できる-ErrorVariableパラメータというものがあります。

このパラメータは下記のようにして使用します。

PS C:\Work> Get-ChildItem HIRO1.txt -ErrorVariable err1
Get-ChildItem : パス 'C:\Work\HIRO1.txt' が存在しないため検出できません。
発生場所 行:1 文字:14
+ Get-ChildItem  <<<< HIRO1.txt -ErrorVariable err1

-ErrorVariableパラメータの後ろには、エラー内容を代入するための変数を指定します。

このとき指定する変数に$を付加してはいけないことに注意してください。

以前紹介した$Error変数は、PowerShellの操作時に発生したすべてのエラーが格納されますが、この-ErrorVariableパラメータを使用した場合は、そのとき発生したエラーの内容だけを特定の変数に代入できるという違いがあります。

CodeZineでPowerShell入門(7)  関数編2 が公開になりました。

よろしかったらみてくださいね。

それ以前の記事は下記の通りです。

PowerShellでは、エラーが発生した場合の振る舞いを変更することが可能です。

振る舞いの変更方法には2種類あり、コマンドレットごと、またはすべてのエラーに対して設定できます。

コマンドレットごとに指定する場合には -ErrorActionパラメータを、すべてのエラーに対して共通の振る舞いを行うようにするには$ErrorActionPreference変数を設定します。

設定可能な値は3つありますので、それぞれについてみてみましょう。

continue

デフォルトではContinueになっています。エラーが発生した場合はメッセージが出力されます。

エラーの内容は$Error変数に追加され、$?変数はfalseとなります。スクリプトは次の行から実行されます。

silentlycontinue

エラーが発生してもメッセージは出力されません。

エラーの内容は$Error変数に追加され、$?変数はfalseとなります。スクリプトは次の行から実行されます。

stop

エラーが発生してもメッセージは出力されません。

エラーの内容は$Error変数に追加され、$?変数はfalseとなります。スクリプトは停止します。

-ErrorActionパラメータの使用方法

-ErrorActionパラメータに"continue"を設定した場合はエラーメッセージが出力されます。

PS C:\Work> Get-ChildItem HIRO -ErrorAction "continue"
Get-ChildItem : パス 'C:\Work\HIRO' が存在しないため検出できません。
発生場所 行:1 文字:14
+ Get-ChildItem  <<<< HIRO -ErrorAction "continue"

-ErrorActionパラメータに"silentlycontinue"を設定した場合はエラーメッセージが出力されません。

PS C:\Work> Get-ChildItem HIRO -ErrorAction "silentlycontinue"
PS C:\Work>

$ErrorActionPreference変数の使用方法

$ErrorActionPreference変数へcontinueを設定する場合は下記のようにします。

PS C:\Work> $ErrorActionPreference = "continue"

$ErrorActionPreference変数へsilentlycontinueを設定する場合は下記のようにします。

PS C:\Work> $ErrorActionPreference = "silentlycontinue"

この状態で、さきほどエラーが発生したコマンドを実行してみましょう。

PS C:\Work> Get-ChildItem HIRO
PS C:\Work>

今度はエラーメッセージは表示されません。

$ErrorActionPreference変数にsilentlycontinueを設定した効果が現れていることがわかります。

このように、-ErrorActionパラメータや$ErrorActionPreference変数は、エラー発生時の振る舞いを変更することが可能ですので、ぜひ仕様用途に応じて使い分けてみてください。

$?変数というものがあります。

これは処理全体が成功した場合にはtrue、それ以外の場合はfalseとなります。

この変数を使用すると、エラーメッセージが表示されなくてもエラーが発生したかどうかを確認できるため、スクリプトの中で使用すると効果を発揮します。

まずは、この変数の動きを見てみましょう。

なにもエラーが発生していない状態で$?変数の中身を確認すると

PS C:\Work> $?
True

上記のようにTrueを返します。

しかし下記のようにエラーを発生させると

PS C:\Work> dir HIRO2.txt
Get-ChildItem : パス 'C:\Work\HIRO2.txt' が存在しないため検出できません。
発生場所 行:1 文字:4
+ dir  <<<< HIRO2.txt
PS C:\Work> $?
False

上記のようにfalseを返します。

ではスクリプトの中でどう使用すればよいか？

1つ例を挙げたいと思います。

下記はdirコマンドを使用していますが、リダイレクトを使用してエラーを変数に代入するようにしています。

このためエラーはコンソールへは表示されません。

エラーメッセージが表示されないので、見た目にはエラーが発生したかどうかを確認できませんが、$?変数の中身を確認すれば、dirコマンドの実行結果が成功したか失敗したかを確認できるので、独自のエラー処理を記述することが可能です。

PS C:\Work>  $ret1 = dir HIRO 2>&1
PS C:\Work> if ( ! $? ) { "エラーが発生しました" }
エラーが発生しました

このように$Error変数や$?変数を使用すれば、エラーに対する処理を記述しやすくなりますので是非活用してみてください。