2017/12/24

Posted: 12:41:51 |

この記事には「 独自研究 」に基づいた記述が含まれているおそれがあります。

この記事はPowerShell Advent Calendar 2017の24日目です。

一般的なプログラミング言語では、文（statement）と式（expression）の違いは、値を返すのが式で、返さないのが文、という説明がされることが多いと思います。しかし、PowerShellではこの説明は成り立たたず、文が値を返したりしてるように見えて良く分かりません。そこでPowerShellにおける文と式とはそもそも何なのかということを、仕様書（PowerShell 3.0のものですが）やAST（ShowPSAstモジュールが便利！）を眺めながら考えてみたので軽くまとめようと思います。

文（statement）と式（expression）の定義

PowerShellでは言語要素として、文（statement）と式（expression）が明確に定義されています。すなわち、言語要素の何が文であって、何が式であるかという定義は仕様できちんと決まっていて、ある言語要素が、状況によって文になったり式になったりと変化する、ということはありません。

パイプライン、代入、ifやforやfunctionなどは文です。

変数、数値/文字リテラル、オブジェクトのメンバ呼び出し、スクリプトブロック、単項または二項算術演算子で構成される式、カンマ演算子で構成される配列などは式です。

ただ、仕様書での定義と、実際に構築されるASTに齟齬があることはあります。

例えば「$a=1」のような代入については、ASTではAssignmentStatementAstとなります。一方、言語仕様上はassignment-expressionと書かれています。厳密には、言語仕様書のgrammer節によれば、assignment-expressionはexpressionではなくpipelineであるということになっています（お前は何を言っているんだ）。いずれにせよパイプラインは文であるので、AST通り、代入は文であるという解釈で良いと思います。

※仕様書にはassignment expressionとはっきり書いてあるんだから代入は式だろ！という意見を否定するものではないです。が、代入は文であると考えたほうが他の文法と整合性を取りやすいので、そういう立場をとりました。

しばたさんが9日目に書かれた記事で取り上げられているように、配列に関しても同様の齟齬があります。いずれにせよ「1,2,3」のような配列は、式と考えて良いと思います。

文と式の構造

PowerShellには文と式が存在することは分かりました。では文と式は何が違うのか？　それを考察するために、具体的にいくつかの文と式の構造を取り上げて見ていきます。

パイプライン（文）

パイプラインといえば「Get-Process | Where-Object Handles -gt 100 | Select-Object ProcessName」みたいな|で繋ぐやつのことでしょ、と思われがちですが、言語仕様上は以下のようなものはすべてパイプラインです。

Get-Process -Name PowerShell # ①コマンド1つだけ
1 # ②数値リテラルだけ
1 + 1  # ③算術演算子で構成される算術式
$a = 1 # ④代入
gps | where Handles -gt 100 | select ProcessName # ⑤パイプ記号でコマンドを連結したもの
1 + 1 | Write-Host # ⑥算術式をパイプラインでコマンドと繋げたもの

要はパイプラインというのは、一般的なプログラミング言語で、;で終わる一文に相当するものと考えればだいたい間違いないと思います。ただしPowerShellだと文末の;は必須ではなく、改行でもOKです。

パイプラインは以下のような構造を取ります。[]は省略可能を意味します。

パイプライン要素1 [ | パイプライン要素2] [ | パイプライン要素3] ...

または、

代入文

すなわち、代入文（後述）を除くパイプラインは1個以上のパイプライン要素から構成されており、複数のパイプライン要素が存在する場合はパイプ演算子|で連結されます。

パイプライン要素には式とコマンド（Get-Processとか）が存在します。ただし式は1つ目のパイプライン要素にのみ許可されます。

以上を踏まえると、①、⑤はコマンドのみで構成されるパイプライン、②、③は単独の式のみで構成されるパイプライン、⑥は1つの式とコマンドで構成されるパイプライン、④は代入文であることが分かります。

代入文

代入文はパイプラインなので、文です。代入文は以下のような構造を取ります。（ここでは+=などの複合代入演算子については省略）

式 = 文

ただし、左辺の式は、変数やプロパティなど、代入が可能な式である必要があります。

よって以下のような記述が可能です。

$a = $b # ①変数
$a = 1 + 1 # ②算術式
$a = Get-Process # ③パイプライン（コマンド1つ）
$a = gps | where Handles -gt 100 # ④パイプライン（コマンド複数）
$a = if($true){"a"}else{"b"} # ⑤if文
$a = $b = 1 # ⑥代入文の結果を更に代入

言語仕様上、代入文の右辺には文であれば何でも書けるのですが、実際に代入が行われるのは、パイプライン、if文、for文、switch文といった、パイプラインに値を出力する文と代入文に限られます。ちなみに⑤のようにパイプラインと代入文以外の文を右辺に指定できるようになったのは、PowerShell2.0からです。

ところで上記①や②は右辺が式です。代入文の右辺は文じゃなかったの？と思われると思いますが、パイプラインの節で述べた通り、単独の式もパイプラインであり、パイプラインは文なので、三段論法でいくと式は文として扱われることになります。

※AST上では$a = $bの右辺はPipelineAst/CommandExpressionAst/VariableExpressionAstではなく、いきなりCommandExpressionAst/VariableExpressionAstとなっているので、この説明はASTの実装とはかみ合わないかもしれません。AssignmentStatementAst.Rightは確かにStatementAstを取るのですが、CommandExpressionAstはStatementAstから派生しているクラスなので、式の代入は問題なく行えます。

代入文は上記⑥のようなことができることから分かる通り、値を返す文ですが、パイプラインには値を出力しません。値は返すがパイプライン出力がないものは、インクリメント演算子で構成される式（$a++等）も同様です。

if文

パイプラインと代入文以外の文は色々あるわけですが、代表的なものとしてif文を取り上げます。一番シンプルなif文はこういう構造です。

if (パイプライン) {
    文1
    文2
....}

おそらく多くの人が誤解しているのではないかと思いますが、条件節に書くのは式ではなくパイプラインです。パイプラインを実行した結果、出力値がtrue、またはboolに型変換してtrueになる場合に、ブロック内の複数の文が実行されます。

よって以下のような記述が可能です。

if ($true) {} # ①変数
if ($a -eq 1) {} # ②論理演算子で構成された式
if ("a.txt" | Test-Path) {} # ③パイプライン
if ($a = 1) {} # ④代入文

①と②は普通の書き方ですが、実際には、1つの式のみ有するパイプラインを実行し、出力される値が判定されています。

条件節はパイプラインなので、当然③のような書き方もできるわけです。また、代入文もパイプラインであるので、④の書き方もできてしまい、注意を要します。

条件節に指定できるのはパイプラインだけで他の文は許容されないので、
if (if($true){}){}
というような書き方はできません。

※といっても実はこう書くと文法上はvalidであり、条件節内は「ifコマンド、パラメータ値1（$true）、パラメータ値2（スクリプトブロック）」という解釈になってしまいます。

また、条件節にはパイプラインは1つのみ指定可能で、複数文を書くことはできないので、
if ($a;$b) {}
という書き方はできません。（パーサーもエラーを出す）

丸括弧式

さて、普通のプログラミング言語だと、()はグループ化や演算子の優先順を変更するのに用いられるものの、別に文法そのものに影響を与えるものではないと思います。多くの場合、ASTでも()の情報はそぎ落とされます。

ところがPowerShellでの丸括弧()は文法的な意味を有しており、ASTにもParenExpressionAstとして存在する、立派な式です。丸括弧式の構造は以下の通りです。

(パイプライン)

これは要するに、「パイプラインに()を付けると式になる」、ということです。()内のパイプラインで出力された値が返される式となります。具体的にどういうところで使うのかを示します。

2 * (1 + 3) # ①数値演算の優先順を変更する
($a = 1) # ②値を返すがパイプラインには出力しない代入文の値を出力させる
$a[(Get-Hoge)] # ③式は許容するがパイプラインは許容しない構文で、式に変換する
Get-Process -Name (Get-Hoge) # ④コマンドのパラメータにコマンド実行結果を指定する

①の使い方は普通です。ただし、()はパイプラインを生成するので、「(1+3)」は「1つの式のみ有するパイプラインを実行し、パイプラインに値を出力し、その値を返す」という見た目より複雑な処理になります。

※少なくともAST上はそうなりますが、実際は何らかの最適化処理が入ってる可能性はあります。

代入を重ねる場合には②のような書き方は必要ないのですが、代入した結果をパイプラインの出力としたい場合は()を付ける必要があります。この場合、$aに1が代入され、コンソールにも1が出力されます。

③で挙げている、式を許容するがパイプラインは許容しない言語要素というのは実はあまりないです。前述した通りif文の条件節は式じゃなくて、パイプラインを取るといった案配です。ただ、たとえば配列や連想配列の要素を取得するインデックス演算子[]は、式のみ許容されます。なのでコマンドなどのパイプラインの出力値を指定したい場合は()が必須となるわけです。

ちなみに、()内にはパイプライン以外の文（if文等）は指定できません。また、複数のパイプラインも指定できず、あくまで1つだけです。

※任意の文あるいは複数の文を式としたい場合には、部分式演算子$()または@()を用います。両者とも内部の文がパイプラインに出力した値を返す、「部分式」となります。両者とも複数値が出力されると配列になりますが、@()は出力値が1つでも要素数1の配列を返す点が異なります。

まとめ？

PowerShellの文と式は厳密に定義されています。文は複数の文と式で構成されるし、式は複数の文と式で構成されています。文や式の構成要素が取る文や式の種類についても、各々、きちんと定義されています。

ただし、PowerShellにおいて「値を返すか返さないか」、「パイプラインに出力されるかされないか」、「式であるか文であるか」という概念はすべて独立しています。そのため、PowerShellの文とは何である、式とは何である、ということを一言で説明することは難しいんじゃないかと思います。

なので、本記事でこれまで述べてきたとおり、「パイプラインは文で、要素として式やコマンドを取りますよ」とか、「ifは文で、条件節にはパイプラインを取りますよ」みたいな、各論でしか表現できないのではないかなぁと、私はそういう結論に至りました。

しかしここまで書いてちゃぶ台をひっくり返すようなことを言いますが、ある言語要素が文であるか式であるか、ここまで仕様書を読んだりASTを追ったりして把握するのは、まあ楽しくなくはないですが、知らなくても別に大丈夫だと思われます。別に、ifの条件節には条件式を書くのだと理解していても不都合は特にないかと。

効用があるとすれば、例えば「if ((Test-Path a.txt)) {}」とか「foreach ($i in (1..5)) {}」とかの、余分な()を取り除くのには文法の知識が役立ちます。それもまぁ、心配だから怪しい所には常に()付けておく or 何か変だったら()付けてみる　とかでもそれ程問題にはならないかもしれません。

2015/04/14

Posted: 04:39:03 |

JPPOSH（Japan PowerShell User Group）主催の、第5回PowerShell勉強会を5/9(土)に開催します。大阪での開催は3回目になります。会場はMicrosoft関西支店です。

セッションはお昼1時から4セッションあり、PowerShell大阪勉強会主催のwakaさんによる、「スクリプトの書き方」、私による「PowerShell 5.0 新機能」、ALM MVPのPosauneさんによる「C#er的Powershellの使い方」、岩城さんによる「PowerShellで行うOffice365の管理＆メンテナンス」とのラインナップになっています。

今回は開発者視点の話が中心になりそうですが、基本的なスクリプトの書き方から実務への応用、そしてそろそろ全貌が見えてきた次バージョンの話まで、幅広く対応できる内容かと思います。ご興味のある方は、ぜひ、ご参加くださいませ。

今回の開催日は、アメリカで開催される大型カンファレンスである、Build 2015およびMicrosoft Igniteの直後ということもあって、私のセッションでは可能な限り両イベント開催中に新しく発表された情報を反映していこうと思っています。

先日発表になったばかりの、Windows Serverのコンテナ実行環境である、Nano Serverの詳細や、その上で動作するPowerShellの話なんかが出てくるんじゃないかなぁと思っていますが、どうでしょうね？　お楽しみに。

2015/01/06

Posted: 05:09:59 |

あけましておめでとうございます。

2015年、直近の私のセッション予定について告知します。ご都合がよければ、ぜひぜひお越しくださいませ。

2015/01/31(土)

イベント：2015 MVP Community Camp （大阪会場）

タイトル：「PowerShellスクリプトを書いてラクしよう」

セッション概要：

コンピューター上で定型作業を手動でちまちまやるのは効率が悪いです。スクリプトを書いて自動化しましょう。幸い、最近のWindowsにはPowerShellというステキな環境が最初から入っています。これを使わない手はありませんね！ PowerShellはサーバー管理の自動化ツールとして重要ですが、本セッションではPowerShellでのスクリプトの書き方を、まずは身近なテーマの具体例を交えて伝授いたします。もうすぐリリースされるv5.0の紹介もちょっとだけします。

ひとこと：

日本を含むアジアパシフィック地域で同時開催されるコミュニティイベント、2015 MVP Community Camp の大阪会場で、わんくま同盟大阪勉強会代表としてセッションさせていただきます。

今回のイベントのテーマとして、最新の技術をわかりやすく、初心者や学生に伝えるというのがあります。そこで私の方からは、初心に返って、本来PowerShellがターゲットとしているサーバーOSというよりかは、クライアントOSで日常的に使えそうなスクリプトを題材に、PowerShellの紹介をしていこうと思っています。

なお、大阪会場ではJapan PowerShell User Group大阪の主催者であるwakaさんによる「PowerShellで変わるサーバ構築と管理」というセッションもあります。こちらはPowerShellによるサーバー構築、管理のお話なので、どちらかというと本筋の話だと思います。併せてぜひ、どうぞ。

2015/02/14(土)

イベント：オープンセミナー2015@広島

タイトル：「PowerShell DSCによるインフラ構成管理の自動化手法について」

セッション概要：

PowerShell Desired State Configuration（DSC）の登場により、いよいよWindows Server、Microsoft AzureでもInfrastructure as Code（インフラ構成をコード記述により自動化する手法）が可能となりました。 またWindowsのみならずLinuxなど他プラットフォームについてもDSCで横断的に構成管理を行える世界が来ようとしています。 本セッションでは、PowerShell DSCを用いた最新のMicrosoft系インフラ構成管理の手法について、間もなくリリースされる予定のPowerShell 5.0の新機能も交えて紹介したいと思います。

ひとこと：

オープンセミナー広島というIT系無料セミナーでセッションをさせていただくことになりました。2015のテーマは「クラウド時代の構成管理入門」ということで、私の方からはPowerShell DSCをキーワードに、Windows Server、Microsoft AzureといったMicrosoft系サーバー、クラウド環境の構成管理のお話をします。

これまでずっと、どちらかというとMicrosoft系のイベントばかりでセッションしてきたので、ちょっとドキドキしています。

今回のイベントでは、Chef、Docker、Ansibleなど旬のお話が聞けるので私も勉強しにいこうと思っています。ご存じのとおり、Microsoftの昨今の戦略変更で、これからはMicrosoft技術のみならず、オープンソースのソフトウェアについてもちゃんと知っておかないといけませんし！

2015/03/14(土)？

イベント：わんくま同盟大阪勉強会

タイトル：「未定」

ひとこと：

PowerShell関係で何かセッションをしようと思っています。

2014/10/12

Posted: 15:00:07 |

昨日10/11のPowerShell勉強会#4にお越しいただいた方、どうもありがとうございました。スタッフ一同、これからも定期的に開催していこうと考えておりますので、ぜひともよろしくお願い致します。

私のセッション資料を公開します。わんくま横浜で行ったものとほとんど同じですが、v5関係のスライドを少しだけ修正しています。

今回は高度な関数とコマンドレットの作り方を主に取り上げていますが、要するに、PowerShellコマンドはPowerShellスクリプトでもC#でもほぼ同じようにして同じようなものが書ける、ということなのです。なので、基本を押さえればどちらにも対応可能です。

両者は状況に応じて使い分ければOKかと思います。PowerShellよりC#が得意、というならばコマンドレットを書くと良いですし、スクリプト的なお手軽なコードで書きたい場合は高度な関数、とかですね。

速度が求められる部分とか、.NETアセンブリを多用する部分だけコマンドレットにして、他を高度な関数にする、あるいは、主要部はコマンドレットにして、その他はコマンドレットのラッパー的な高度な関数を用意する、のように両者を組み合わせたモジュールもよくあります。

以下はデモ用のサンプルスクリプトです。高度な関数の雛型的なものになります。使い方はスライド本文を参照してください。

function Get-Foo
{
    [CmdletBinding()]
    param([string[]]$Name)
    end
    {
        foreach($n in $name)
        {
            $out = [pscustomobject]@{
                Name = $n
                No = 0 
            }
            # PSCustomObjectのインスタンスに型名を付ける
            $out.PSTypeNames.Insert(0, "Winscript.Foo")
            $out
        }
    }
}

function Set-Foo
{
    [CmdletBinding()]
    param(
        [parameter(ValueFromPipeLine=$true, Mandatory=$true, Position=0)]
        [PSObject[]]
        $InputObject,
        [parameter(Position=1)]
        [string]
        $Property,
        [parameter(Position=2)]
        [PSObject]
        $Value,
        [switch]
        $PassThru
    )
    process
    {
        foreach($o in $InputObject)
        {
            $o.$Property = $Value
            if($PassThru)
            {
                $o
            }
        }
    }
}

# C#によるクラス定義
Add-Type -TypeDefinition @"
using System;
namespace Winscript
{
    public class Foo2
    {
        private string _name;
        private int _no;
        public Foo2(string name)
        {
            _name = name;
            _no = 0;
        }
        public string Name
        {
            get{
              return _name;  
            }
            set{
               _name = value; 
            }
        }
        public int No
        {
            get{
              return _no;  
            }
            set{
               _no = value; 
            }
        }
    }
}
"@

function Get-Foo2
{
    [CmdletBinding()]
    param([string[]]$Name)
    end
    {
        foreach($n in $name)
        {
           New-Object Winscript.Foo2 $n
        }
    }
}

function Set-Foo2
{
    [CmdletBinding()]
    param(
        [parameter(ValueFromPipeLine=$true, Mandatory=$true, Position=0)]
        [Winscript.Foo2[]]
        $InputObject,
        [parameter(Position=1)]
        [string]
        $Property,
        [parameter(Position=2)]
        [PSObject]
        $Value,
        [switch]
        $PassThru
    )
    process
    {
        foreach($o in $InputObject)
        {
            $o.$Property = $Value
            if($PassThru)
            {
                $o
            }
        }
    }
}

以下はデモで用いたC#のコードです。コマンドレットクラスの雛型的なものになっています。ビルドの際はSDKに含まれるPowerShell関係のdllを参照設定してください（詳しくはスライド）。また使用する際は、Import-Module ビルドで生成したdllのフルパス　を実行してインポートして下さい。以下の例だとGet-Baz、Set-Bazの2コマンドレットがインポートされます。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Management.Automation;

namespace Winscript
{
    [Cmdlet(VerbsCommon.Get, "Baz")]
    public class GetBazCommand : Cmdlet
    {
        [Parameter(Mandatory = false, ValueFromPipeline = false, Position = 1)]
        public string[] Name { get; set; }

        protected override void ProcessRecord()
        {
            foreach (var n in Name)
            {
                WriteObject(new Baz(n));
            }
        }
    }

    [Cmdlet(VerbsCommon.Set, "Baz")]
    public class SetBazCommand : Cmdlet
    {
        [Parameter(Mandatory = true, ValueFromPipeline = true, Position = 0)]
        public Baz[] InputObject { get; set; }

        [Parameter(Mandatory = true, ValueFromPipeline = false, Position = 1)]
        public string Property { get; set; }

        [Parameter(Mandatory = true, ValueFromPipeline = false, Position = 2)]
        public PSObject Value { get; set; }

        [Parameter(Mandatory = false, ValueFromPipeline = false)]
        public SwitchParameter PassThru { get; set; }

        protected override void ProcessRecord()
        {
            foreach(var o in InputObject)
            {
                if (Property == "No")
                {
                    o.No = (int)Value.BaseObject;
                }
                else if(Property == "Name")
                {
                    o.Name = (string)Value.BaseObject;
                }
                if (PassThru)
                {
                    WriteObject(o);
                }
            }
        }
    }

    public class Baz
    {
        private string _name;
        private int _no;
        public Baz(string name)
        {
            _name = name;
            _no = 0;
        }
        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                _name = value;
            }
        }
        public int No
        {
            get
            {
                return _no;
            }
            set
            {
                _no = value;
            }
        }
    }
}

2014/09/25

Posted: 22:13:13 |

第 4 回 PowerShell 勉強会 - Japan PowerShell User Group (JPPOSH) | Doorkeeper

というわけで、10/11(土)、大阪のマイクロソフト関西支店にて、第4回PowerShell勉強会が開催されます。大阪では2回目ですね。

今回は開発者向けのセッションが中心となっている感じです。

かめがわさんの、Release ManagementとPowerShell DSCを用いたリリース認証フローの実装のお話、おおたさんの開発者視点でのPowerShell活用法のお話、私はコマンド（コマンドレット、高度な関数）の書き方についての話をします。そして今回も東京からぎたぱそさんが参戦して何か話してくれるそうですよ。

今回は、LTも募集してます。我こそは、という方はぜひご登壇を！

それでは皆さま、10/11にはぜひぜひ、PowerShell勉強会にお立ち寄りくださいませ。

2014/09/09

Posted: 18:55:19 |

8/23わんくま横浜勉強会で、PowerShellコマンドの書き方というセッションをしたのですが、その際、株式会社Codeerさんが公開されているFriendlyというライブラリを使ったコマンドレットを動作させるデモを行いました。

準備の時間がなくて、突貫工事で作ったサンプルで恐縮ですが、公開することにします。（一応動かしてみたら動いた、レベルのものなのであしからず…）

コード
using System;
using System.Diagnostics;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Management.Automation;
using Codeer.Friendly.Windows;
using Codeer.Friendly.Dynamic;
using System.Windows.Forms;

namespace Winscript
{
    [Cmdlet(VerbsCommon.Get, "FormControlText")]
    public class GetFormControlTextCommand : Cmdlet
    {
        [Parameter(Mandatory = false, ValueFromPipeline = false, Position = 1)]
        public string[] ControlName { get; set; }

        [Parameter(Mandatory = true, ValueFromPipeline = true, Position = 0)]
        public Process Process { get; set; }

        protected override void ProcessRecord()
        {
            var _app = new WindowsAppFriend(this.Process);
            dynamic form = _app.Type<Control>().FromHandle(this.Process.MainWindowHandle);
            foreach (var c in form.Controls)
            {
                if (ControlName == null || ControlName.Contains((string)c.Name))
                {
                    WriteObject((string)c.Text);
                }
            }
        }
    }

    [Cmdlet(VerbsCommon.Set, "FormControlText")]
    public class SetFormControlTextCommand : Cmdlet
    {
        [Parameter(Mandatory = true, ValueFromPipeline = false, Position = 1)]
        public string ControlName { get; set; }

        [Parameter(Mandatory = true, ValueFromPipeline = false, Position = 2)]
        public string Text { get; set; }

        [Parameter(Mandatory = true, ValueFromPipeline = true, Position = 0)]
        public Process Process { get; set; }

        protected override void ProcessRecord()
        {
            var _app = new WindowsAppFriend(this.Process);
            dynamic form = _app.Type<Control>().FromHandle(this.Process.MainWindowHandle);
            foreach (var c in form.Controls)
            {
                if (ControlName == (string)c.Name)
                {
                    c.Text = Text;
                }
            }
        }
    }
}
ビルド方法
  1. Windows 8.1 SDK をインストールする。
  2. Visual Studio 2010以降でC#のクラスライブラリを新規作成する。
  3. C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0 にある.dllを参照設定する。
  4. 対象フレームワークを.NET 4.5、対象プラットフォームをx64にする。
  5. 上記のコードを貼り付ける。
  6. NuGetでFriendlyおよびFriendly.Windowsを追加する。
  7. ビルドする。
使用方法

上記をビルドして生成したDLLにはGet-FormControlTextと、Set-FormControlTextの2つのコマンドレットが含まれます。

# コマンドレットのインポート
Import-Module "dllのフルパス"

# 操作対象のプロセスオブジェクト取得
$p = Get-Process WindowsFormsApplication1 

# プロセスを指定して、すべてのコントロールのテキストを取得
Get-FormControlText -Process $p

# プロセスとコントロール名を指定して、テキストを取得
Get-FormControlText -Process $p -ControlName textBox1

# 位置パラメータなので以下のようにも書ける
Get-FormControlText $p textBox1

# パイプラインからプロセスオブジェクトを入力することもできる
$p | Get-FormControlText -ControlName textBox1 

# プロセスとコントロール名を指定して、テキストを変更する
Set-FormControlText -Process $p -ControlName textBox1 -Text Wankuma
Set-FormControlText $p textBox1 Yokohama
$p | Set-FormControlText -ControlName textBox1 -Text 6
制限事項

フォーム直下に配置されたコントロールしか取得できない（と思います）。

Windows Formアプリケーションにしか対応していない（と思います）。

x64アプリしか操作できない（と思います。x86用はアセンブリを分ける必要がある？？）。（←9/9追記）

コントロール名指定はCase sensitiveでワイルドカード不可です。（この辺ただの手抜きですが）

今後の方針？

上のコードをみてもらえればわかると思いますが、ちょっと触ってみたら一応動くものができるくらい、Friendlyは分かりやすいです。皆さんもぜひ使ってみてください。

本来は、テキストじゃなくてコントロールそのものをGetしたりSetしたりInvoke（クリックとか）したりできるようにしたかったんですが、Controlはシリアル化できないオブジェクトなので、Friendlyで実物を持ってきてコマンドレットに出力する、というのは無理でした。何らかのプロキシオブジェクトみたいなのでラップしたりすれば良いかと思います。

それにしてもPowerShellとFriendlyの組み合わせはものすごい可能性を秘めている予感がします。

システム管理方面では…

セッションでもやりましたが、PowerShellコマンドレットベースのアプリケーションを作ると、GUIとCUIのいいところどりが出来る、とはいうものの、コマンドインターフェースがなくGUIオンリーのアプリケーションはまだまだたくさんあるのが現実かと思います。そういうアプリケーションも、PowerShellデフォルトの機能のみではつらいですが、上記のようにFriendlyを併用すれば、GUI操作の自動化が容易になると思います。

開発方面では…

C#でFriendlyを使ったGUIのテストコードを書く以外に、上記のようなFriendlyの機能をラップしたコマンドレットを用意することで、PowerShellスクリプトでもテストコードを書くことができるようになると思います。その際、Pester等のPowerShell用テストフレームワークを併用すると、より一貫したテストコードが記述できるようになるんじゃないかと思います。

いずれは（いつ？）、Friendlyの機能をラップしたコマンドレット群をきちんと設計、実装して、モジュールとして公開したいですね！

2014/08/25

Posted: 20:22:40 |

2014/08/23わんくま横浜#06にお越しいただいた方、どうもありがとうございました。

私の「PowerShellコマンドの書き方」というセッションの資料を公開します。

以下、セッション概要の再掲です。

PowerShellのコマンドを記述する方法としては、大きく分けて、.NET言語で記述する「コマンドレット」と、スクリプトで記述する「高度な関数」があります。
他言語の関数などと異なり、PowerShellのコマンドは他コマンドと連携させるためには、パイプラインの動作をきちんと把握して作成する必要があります。
今回はPowerShellのパイプラインの挙動と、それを踏まえたコマンドレットと高度な関数の書き方を解説します。
デモのお題としては、Friendlyを使ったUI操作自動化コマンドなんていかがですかね？

ところで、同内容のセッションを今度は関西でもやる予定です。詳細が決まり次第、ここで告知します。

9/9追記。http://winscript.jp/powershell/282に、本セッションで行ったデモ用のサンプルコードを公開しました。

2014/04/20

Posted: 13:11:29 |

Select-Object、Format-Table、Sort-Objectなど、-Propertyパラメータを持つコマンドレットには、プロパティ名を指定する以外にも「集計プロパティ」という連想配列を指定することができます。

集計プロパティを利用すると、オブジェクトが持っていないプロパティを動的に作成し、その値を表示することができるようになります。

たとえば、dir (Get-ChildItem)の出力するファイルリストに、テキストファイルとして開いた場合の1行目の記述（Textプロパティとする）も合わせて表示したい場合は以下のようにします。

dir | select Name, Extension, @{Name="Text"; Expression={$_|gc|select -First 1}}

出力は以下のようになります。

Name            Extension            Text                              
----            ---------            ----         
test1.ps1       .ps1                 param([Parameter(ValueFro...
test2.ps1       .ps1                 $x=1231                           
test3.ps1       .ps1                 Start-Transcript                  
test4.ps1       .ps1                 Get-Content .\gacha_log.t...

ここで、@{Name="Text"; Expression={$_|gc|select -First 1}}と指定している部分が集計プロパティです。連想配列のキーとしてプロパティ名を表すNameと、スクリプトブロックを指定するExpressionを含めます。なお、キー名のNameはN、ExpressionはEと省略表記できるので、

dir | select Name, Extension, @{N="Text"; E={$_|gc|select -First 1}}

と書くこともできます。

ここまではヘルプにも載っていることなのでご存知の方も多いと思います。ただ、連想配列を指定してごにょごにょ、というのは（特にインタラクティブ実行時には）正直だるいです。そこでもっと楽な書き方はないものかと思って何気なく、

dir | select Name, Extension, {$_|gc|select -First 1}

とプロパティとしてスクリプトブロックをそのまま書いたら、普通に通りました。これ、知ってました？　私は知らなかったです。しかしv2環境で実行しても動いたので前からあったんですね。なぜヘルプに載ってないのか…。それともどこかに載ってるんでしょうか…。

ただしこの方法だと、集計プロパティでプロパティ名（Nameキー）を指定しない場合と同様、以下のようにプロパティ名がスクリプトブロックの定義そのままになります。

Name          Extension          $_|gc|select -First 1                              
----          ---------          ---------------------         
test1.ps1     .ps1               param([Parameter(ValueFro...

そのため、コマンドの出力を変数に入れて利用する場合などはこの方法は不適です。ですがインタラクティブ実行時で、結果表示の見た目よりも効率を重視する場合なら、この方法はお勧めです。

2013/03/16

Posted: 01:05:12 |

PowerShellのforループで2変数を初期化するにはどうすれば良いのかと、昨日とある方に質問されました。C#やJavaScriptなんかでは

for (int i = 0, j = 10; i < 10; i++, j--){}

のように初期化子を,で区切って複数指定できますが、PowerShellでは

for ($i = 0, $j = 10; $i -lt 10; $i++, $j--){}

という書き方ができません。初期化子部分には一つの変数しか書けないのです。

そこで考えたのが部分式を利用する方法です。部分式は一つの式に複数の文を埋め込むための書式で、

Write-Host "今日は $($d = Get-Date; $d.ToString("M/dd")) です。"

こんな感じで$()の中に複数の文を入れて変数のように実行結果の値を参照できます。なお、部分式の内部は、スクリプトブロックとは違い、外側と同じスコープとなります。

この部分式をforループの初期化子に利用してみます。

for ($($i = 0; $j = 3); $i -lt 3; $i++, $j--)
{
    "$i $j"
}

実行結果は

0 3
1 2
2 1

となりちゃんと動いてますね。

この書き方が果たして正式なものなのか、分かりませんが、forループで複数値の初期化をしたいときに使えるテクなんじゃないでしょうか。

ちなみにPowerShellのforループの初期化子宣言はループ内のスコープにおける変数とはならず、ループの外側でも参照や代入ができてしまいますので注意です。forループの中は別スコープとはならないのですね。それは部分式を使っても同じです。（それだったらforループの前で変数初期化しても同じことじゃん、となるかもしれませんが…）

また例をみていただければ分かりますが、反復式の部分は,で複数指定できるようです。ただしこの,はforステートメントの構文の一部ではなく、配列連結演算子の,だと思います。

追記。エントリ読み返して気づいたんですが、反復式を配列として記述できるのだから、初期化も配列でやっちゃえば良かったですね。このように。

for ($i, $j = 0, 3; $i -lt 3; $i++, $j--)
{
    "$i $j"
}

こっちのほうがいいですね。

2012/12/14

Posted: 02:32:15 |

本記事はPowerShell Advent Calendar 2012の14日目の記事になります。

前回（アドベントカレンダー1日目）は「PowerShellらしい関数の書き方」と題して、パイプライン内でうまく他のコマンドと連携させるための関数をどう書けばいいのか、ということについて書きました。前回の関数の例では入力型と出力型がstringだったのですが、実際は自分で定義した型を入力、出力値に取るように書くのが普通かと思います。今回は、それをするためにどうやって型を定義するのか、そしてその型を関数にどう指定するのか、という話をします。

PowerShellにはクラス定義構文がない

そもそもの話になるんですが、型を定義する、つまりはクラスを記述するためのPowerShellのステートメントやコマンドレットが無いため、PowerShell単独ではできません。なので無理です以上おしまい。…というわけにはいかないので、実際はどうするのがいいのかという話をしていきます。

方法としては大きく分けて二つあると思います。

１．C#など他の.NET言語を用いてクラスを記述する

２．ユーザー定義オブジェクトを作成する

今回は１の方法を説明します。

C#を用いてクラスを記述する

つまりはPowerShellでクラスを定義できないなら、C#を使えばいいじゃない。ということです。幸いPowerShell 2.0からはAdd-Typeというコマンドレットを用いると、C#やVBなど.NET言語のソースをその場でコンパイルしてアセンブリとして現在のセッションに読み込むことが可能です。

たとえば、論理ドライブを表すDriveというクラスを定義してみます。

Add-Type -TypeDefinition @"
    namespace Winscript
    {
        public enum DriveType
        {
            Unknown, NoRootDirectory, RemovableDisk, LocalDisk, NetworkDrive, CompactDisc, RAMDisk
        }

        public class Drive
        {
            public string Name {get;set;}
            public string VolumeName {get;set;}
            public DriveType Type {get;set;}
            public long Size  {get;set;}
            public long FreeSpace  {get;set;}
            public long UsedSpace  {get;set;}
            public string RootPath {get;set;}
        }
    }
"@ -Language CSharpVersion3

このようにC#のコードを文字列として-TypeDefinitionパラメータに与えると、コンパイルされて指定のクラス（ここではWinscript.Drive）がロードされます。

ここで-Language CSharpVersion3というパラメータは指定コードをC# 3.0としてコンパイルすることを指定するため、今回使用している自動実装プロパティなどC# 3.0の構文が利用できます。なおこのパラメータはPowerShell 3.0では不要です。ただし明示しておくとPowerShell 2.0でも正しく動作します。というのも-Languageパラメータ省略時はPowerShell 2.0ではC# 2.0でコンパイルされるのですが、PowerShell 3.0ではC# 3.0でコンパイルするためです（逆にPSv3でC#2.0でコンパイルするには”CSharpVersion2”という新しく追加されたパラメータ値を指定します）。

なお、ここでは-TypeDefinitionパラメータを用いてクラス全体を記述しましたが、この例のように列挙体も定義してそれをプロパティの型にするなどせず、すべて基本型のプロパティで完結するのならば、-MemberDefinitionパラメータを使ってメンバ定義だけを行う方が記述が短くなります。以下はWinscript.Manというクラスを定義する例です。

Add-Type -Namespace Winscript -Name Man -MemberDefinition @"
    public int Age {get;set;}
    public string Name {get;set;}
"@ -Language CSharpVersion3

例のようにC#のコード内には特にロジックを記述せず、単にデータの入れ物となるクラスにとどめておくのが良いかと思います。別にロジックを書いてもいいのですが、ISEで記述する限りはC#の編集に関してはただのテキストエディタレベルの恩恵しか受けないですし、それなら最初からVisual Studio使ってC#で全部コマンドレットとして書けばいいのに、ともなりかねないので。PowerShellでは実現困難な処理などがあればそれをメソッドとして書く程度ならいいかもしれません。ただしメソッドを記述してもそれをユーザーに直接使わせるというよりも、関数でラップして使わせる形が望ましいでしょう。

さて、次はこのクラスのオブジェクトを扱う関数を記述していきます。

定義した型のオブジェクトを扱う関数の記述

ここでは3つの関数を定義しています。Get-Drive関数はシステムに含まれるすべての論理ドライブを取得、Show-Drive関数は指定のDriveオブジェクトをエクスプローラで開く、Set-Drive関数は指定のDriveオブジェクトのボリューム名(VolumeNameプロパティ)を変更するものです。

ちなみに関数の動詞部分（ここではGet, Show, Set）は、Get-Verb関数で取得できるリスト以外のものは基本的に使わないようにします。モジュールに組み込んだ場合、インポートのたびに警告が出てしまうので。

関数の基本については前回に書いているので、今回のコードはそれを踏まえて読んでみてください。

function Get-Drive
{
    [OutputType([Winscript.Drive])]
    param(
        [string[]]$Name,
        [Winscript.DriveType]$Type
    )

    Get-WmiObject -Class Win32_LogicalDisk | ForEach-Object {
        if($null -ne $Name -and $Name -notcontains $_.Name)
        {
        }
        elseif($Type -ne $null -and $_.DriveType -ne $Type)
        {   
        }
        else
        {
            New-Object Winscript.Drive -Property @{
                Name = $_.Name
                VolumeName = $_.VolumeName
                Type = [enum]::Parse([Winscript.DriveType],$_.DriveType)
                RootPath = if($_.ProviderName -ne $null){$_.ProviderName}else{$_.Name + "\"}
                Size = $_.Size
                FreeSpace = $_.FreeSpace
                UsedSpace = $_.Size - $_.FreeSpace
            }
        }
    }
}

（↑10:33 foreachステートメントではなくForEach-Objectコマンドレットを使うように修正。Get-*な関数のようにパイプラインの先頭で実行する関数でも、内部でPowerShellのコマンドレットや関数の出力を利用する場合は、配列化してforeachするよりも、ForEach-Objectで出力を逐次処理した方が良いですね。内部関数の出力がすべて完了してから一気に出力するのではなく、内部関数が1個オブジェクトを出力するたびに出力するようにできるので。）

function Show-Drive
{
    [OutputType([Winscript.Drive])]
    param(
        [Parameter(ValueFromPipeline=$true,Mandatory=$true)]
        [Winscript.Drive[]]
        $Drive,
        
        [switch]
        $PassThru
    )

    process
    {
        foreach($d in $Drive)
        {
            Start-Process $d.Name
            if($PassThru)
            {
                $d
            }
        }
    }
}
function Set-Drive
{
      param(
        [Parameter(ValueFromPipeline=$true,Mandatory=$true)]
        [Winscript.Drive]
        $Drive,
        
        [Parameter(Mandatory=$true)] 
        [string]
        $VolumeName
    )

    process
    {
        Get-WmiObject Win32_LogicalDisk -Filter "DeviceID='$($Drive.Name)'" |
            Set-WmiInstance -Arguments @{VolumeName=$VolumeName} | Out-Null
    }
}

細かい説明は省きますが、前回説明した関数の基本フォーマットに、自分で定義した型を適用してロジックを書くとこうなる、という参考例としてとらえてください。

一つだけ前回に説明し忘れてたことがあります。それは[OutputType]属性です。これは文字通り、関数の出力型を指定するものです。この属性を指定しておくと何が嬉しいかというと、関数の出力を変数に代入したりWhere-Objectコマンドレットでフィルタをかけるコードを記述する際、関数の実行「前」にもプロパティ名をちゃんとタブ補完してくれるようになります。残念ながらこの静的解析機能はPowerShell 3.0からのものなので2.0だとできませんが、OutputType属性自体は2.0でも定義可能なので、定義しておくことを推奨します。

さて、型の定義と関数の定義をしたので実際に関数を実行してみます。

PS> Get-Drive # 全ドライブ取得

Name       : C:
VolumeName :
Type       : LocalDisk
Size       : 119926681600
FreeSpace  : 12262494208
UsedSpace  : 107664187392
RootPath   : C:\

Name       : D:
VolumeName :
Type       : LocalDisk
Size       : 500086886400
FreeSpace  : 198589583360
UsedSpace  : 301497303040
RootPath   : D:\

Name       : Q:
VolumeName :
Type       : CompactDisc
Size       : 0
FreeSpace  : 0
UsedSpace  : 0
RootPath   : Q:\

Name       : V:
VolumeName : 
Type       : NetworkDrive
Size       : 1500299390976
FreeSpace  : 571001868288
UsedSpace  : 929297522688
RootPath   : \\server\D

PS> Get-Drive | where {$_.Size -gt 1TB} # Where-Objectでフィルタ

Name       : V:
VolumeName : 
Type       : NetworkDrive
Size       : 1500299390976
FreeSpace  : 571001868288
UsedSpace  : 929297522688
RootPath   : \\server\D

PS> Get-Drive -Type NetworkDrive | Show-Drive -PassThru | ConvertTo-Csv #ネットワークドライブのみエクスプローラーで開く。取得結果はCSVとして出力。
#TYPE Winscript.Drive
"Name","VolumeName","Type","Size","FreeSpace","UsedSpace","RootPath"
"V:","","NetworkDrive","1500299390976","571001868288","929297522688","\\server\D"
PS> Get-Drive -Name D: | Set-Drive -VolumeName 新しいドライブ # D:ドライブのボリューム名を指定。（管理者権限で）

関数をきちんとPowerShellの流儀に従って記述したおかげで、このようにPowerShellの他の標準コマンドレットと同様の呼び出し方ができ、自作関数やそれ以外のコマンド同士をうまくパイプラインで繋げて実行することができています。

さて、おそらく一つ気になる点があるとすれば、ドライブの容量表示が見づらいということでしょう。容量であればGBとかの単位で表示してほしいですし、大きい数字は,で桁を区切ってほしいですよね。じゃあそういう値を文字列で返すプロパティを定義してやる必要があるというかと言えばそんなことはなく、PowerShellには型に応じた表示フォーマットを指定する方法が用意されています。次回はそのあたりを解説しようと思います。

また、C#とかめんどくさいしもうちょっと楽な方法はないのか？ということで、最初の方でちょっと触れた、ユーザー定義オブジェクトを利用する方法も、余裕があれば次回に。

さて、PSアドベントカレンダー、明日はsunnyoneさんです。よろしくお願いします！

古い記事のページへ |

Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Books

【改訂新版】 Windows PowerShell ポケットリファレンス
書籍版 電子書籍版

Twitter