検索： "dll" - PowerShell Scripting Weblog

2017/12/10

PowerShellで利用するテキストデータ形式の比較

Posted: 05:05:56 |

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

PowerShellはオブジェクトを扱うシェルですが、別にテキストデータを扱えない訳ではありません。むしろ、PowerShellで取得したデータをテキストファイルとして保存したり、スクリプトで用いるデータをテキストファイルで保存しておくことは日常的に行われることだと思います。

ただし、PowerShellで扱うデータはオブジェクトであり、テキストファイルは文字通り文字列であることから、コマンドレットを用いる等、何らかの手段で変換が必要になります。また、テキストデータ形式にも様々な種類があり、それぞれメリット、デメリットが存在します。今回の記事では、PowerShellで用いるデータを保持しておく際のテキストデータ形式について比較をしてみます。

プレーンテキスト

プレーンテキスト、すなわち書式なしのテキストファイルです。もっともシンプルな使い方をする場合、文字列配列の各要素に含まれる文字列が、テキストファイルの1行と対応します。

書き出し

$lines | Set-Content -LiteralPath file.txt -Encoding UTF8

$linesは文字列変数です。

特に理由がなければ文字コードはUTF-8で良いと思います。

追記

$lines | Add-Content -LiteralPath file.txt -Encoding UTF8

Add-Contentは実行のたびにファイルを開いて、書き込んでから閉じるという動作をするので、1行ずつforeachで実行するのはNGです。

読み込み

$lines = @(Get-Content -LiteralPath file.txt -Encoding UTF8)

メリット

文字列配列をテキストファイルに書き出すのは多分これが一番楽だと思います。
書き出したデータは人間にも読みやすい。編集もしやすい。

デメリット

文字列だけを保存しておきたいというケースがそもそも少ない。

CSV

コンマ等の特別な文字で区切り、1行あたりに複数のデータを保存できる形式です。

PowerShellのコマンドレットで扱う場合、オブジェクトが持つプロパティがヘッダ列名に対応します。各行にオブジェクト配列1要素のプロパティ値が、カンマ区切りで保持されます。

書き出し

$objects | Export-Csv -LiteralPath file.csv -NoTypeInformation -Encoding Default

$objectsは任意のオブジェクト配列です。必要であればSelect-Objectコマンドレットを併用して、プロパティを絞り込みます。

文字コードはExcelでそのまま読み込み/書き出しができるDefault（日本語環境ではShift_JIS）がお勧めです。（最近のExcel2016ならUTF8も一応読めますが）

追記

$objects | Export-Csv -LiteralPath file.csv -Append -NoTypeInformation -Encoding Default

読み込み

$objects = Import-Csv -LiteralPath file.csv -Encoding Default

メリット

オブジェクトのプロパティ値が、すべて数値あるいは文字列で表現できる値を持つ場合に最も適合する。
人間にも読みやすく、ある程度は編集もできる。
Excelで開ける。

デメリット

オブジェクトのプロパティが、数値と文字列以外のオブジェクトである場合、すなわち、階層構造を持つデータの保存には適さない。
数値も文字列として読み込まれてしまうので、数値として扱いたい場合は変換が必要になる。
Export-CsvとImport-Csvで扱うCSVファイルはヘッダが必須。つまり、ヘッダなしのCSVファイルが既にあって、それを読み書きするという用途には適さない。（できなくはないが）
書き出し時の列順を制御することができない。つまり、PowerShellで書き出したCSVを、列順が固定であるとの想定である他のプログラムで読み込むことは基本NG。
書き出し時、1つ目の要素に存在しないプロパティは、2つ目以降では存在しないものとして扱われる。同種のオブジェクトで構成される配列なら通常は問題ないのだが、要素によって動的に追加されるプロパティがあったりなかったりすると厄介。（ADでありがち）

JSON

JavaScriptのような表記でデータを保持するデータ形式です。データの受け渡しに様々な言語で利用できます。Web APIでもよく利用されます。

PowerShellではv3からJSONを扱うコマンドレットが提供されています。

書き出し

$objects | ConvertTo-Json | Set-Content -LiteralPath file.json -Encoding UTF8

読み込み

$objects = Get-Content -LiteralPath file.json -Encoding UTF8 -Raw | ConvertFrom-Json

メリット

CSVと異なり、階層構造を持ったデータでも扱える。
CSVと異なり、数値は数値型のまま読み書き可能。（整数値はint、小数値はdecimal）
人間にもまぁまぁ読めるし、頑張れば編集できなくもない。

デメリット

-Depthパラメータによりプロパティを展開する階層の深さを指定はできるが、プロパティに応じて深さ指定を変化させるというようなことはできない。基本的には、自分で構築したPSCustomObjectを使うか、JSON化する前に自分で元オブジェクトを整形しておく必要がある。
直接ファイルに書き出し、追記、ファイルから読み込みするコマンドレットはない。
実は細かい話をしだすと色々と罠があります…。

CLIXML

PowerShellではPSリモーティング等、プロセス間でオブジェクトのやり取りを行う際に、CLIXML形式を介してシリアライズ/デシリアライズが実行されます。シリアライズ対象によっては、完全に元のクラスのオブジェクトに復元されます。（復元されないオブジェクトにはクラス名にDeserialized.との接頭辞が付与され、プロパティ値のみ復元される）

ユーザーもコマンドレットを用いて、任意のデータをCLIXML形式でシリアライズし、XMLファイルとして保存することができます。

書き出し

$objects | Export-Clixml -LiteralPath file.xml

読み込み

$objects = Import-Clixml -LiteralPath file.xml

メリット

元のオブジェクトの構造、プロパティ値と型情報を含めてほぼ完全にテキストファイルに保存できる。
復元したオブジェクトはプロパティ値を参照できるのはもちろん、オブジェクト全体が完全にデシリアライズされ、元の型に戻った場合には、メソッドを実行することも可能。
例え元の型に戻らず、Deserialized.との接頭辞が付いた状態でも、コンソールに表示する場合は元の型のフォーマットが使われるので見やすい。

デメリット

すべてのオブジェクトが元の型に戻せるわけではない。戻せるかどうかは確認が必要。
人間が読み書きするようなものではない。

ちなみに、ConvertTo-Xmlという似たようなコマンドレットがありますが、出力形式はCLIXMLではない上、復元の手段もなく、かといって別に読みやすいXMLというわけでもなく、正直何のために使うのかよく分かりません（適切なxsltでも用意すればいいのかな？）。まだConvertTo-Htmlの方が使えそうです。

psd1

psd1は「PowerShellデータファイル」で、モジュールマニフェストやローカライズデータに使われるファイル形式です。スクリプトファイルの1種ですが、数値や文字列リテラル、配列、連想配列、コメントなど基本的な言語要素のみ使用可能です。PowerShell 5.0以降ではImport-PowerShellDataFileコマンドレットを用いて、任意のpsd1ファイルのデータを読み込み、変数に格納することが可能です。

書き出し

書き出し用のコマンドレットはありません。

読み込み

例えば以下のような内容をbackup_setting.psd1として保存しておきます。ルート要素は必ず連想配列にします。

@{
	Directories = @(
		@{
			From = "C:\test1"       # コピー元
			To = "D:\backup\test1"  # コピー先
			Exclude = @("*.exe", "*.dll")
			Recurse = $true
		},
		@{
			From = "C:\test2"
			To = "D:\backup\test2"
			Exclude = @("*.exe")
			LimitSize = 50MB
		},
		@{
			From = "C:\test3"
			To = "D:\backup\test4"
		}
	)
	Start = "0:00"
}

なお、dataセクションで全体を括ってもいいですが、psd1で許容される言語要素はdataセクションより更に制限がきついので、敢えてしなくてもいいんじゃないかと思います。

このファイルは以下のように読み込めます。

$setting = Import-PowerShellDataFile -LiteralPath backup_setting.psd1

$settingには連想配列が格納され、以下のように値が参照できます。

$setting.Directories | foreach {Copy-Item -Path $_.From -Destination $_.To}

メリット

PowerShellの構文でデータを記述できる。
通常のps1ファイルを呼び出すのとは異なり、式の評価やコマンド実行などはされない分、セキュアである。
配列と連想配列の組み合わせにより、JSONライクな階層構造を持てる。型情報も保持される。
JSONとは違い、コメントが入れられる。

デメリット

記述できるデータはプリミティブなものだけ。
スクリプトから書き出すためのコマンドレットがない。こういうアプローチで頑張ればできるかも？
利用できるのはPowerShell 5.0以降のみ。一応、下位バージョンでやる方法はあります。

まとめ

PowerShellで扱うデータをテキストファイルとして保存する際には、各テキストデータ形式の特性を理解し、メリット、デメリットを踏まえて選定する必要があります。

また、当然ながらテキストファイルに保持することが不適切なデータもありますので、そこは注意してください。（画像データを敢えてBase64とかでエンコードしてテキストファイル化する意味があるのか、とかですね）

個人的には…

ちょっとした作業ログ等を記録しておきたい→プレーンテキスト

.NETオブジェクトの一部のプロパティだけ抜き出してファイル化したい→CSV

自分で構築したPSCustomObjectをファイル化したい→JSON

.NETオブジェクト全体をファイル化したい→CLIXML

スクリプトで使う設定データを用意したい→psd1

みたいな感じでなんとなく使い分けていると思います。psd1はまだ採用例はないですが…。

今回はビルトインのコマンドレットで扱えるもののみ取り上げましたが、他にもyaml等のテキストデータ形式が存在し、有志によるモジュールを用いて扱うことが可能です。

2015/12/10

PowerShellでスクレイピング後編 HTMLをパースする

Posted: 06:58:02 |

この記事はPowerShell Advent Calendar 2015の10日目の記事です。

はじめに

前編では、Invoke-WebRequestコマンドレットやWebClientクラスを用いて、WebページからHTMLの文字列を取得するところまで説明しました。

後編の今回は、取得したHTML文字列をパースして、オブジェクトとして利用可能しやすい形に変換する話です。

IEエンジンによるHTMLパース（DOM）

前編でも触れましたが、Invoke-WebRequestコマンドレットは、レスポンス文字列を取得すると同時に、HTMLをパース（構文解析）し、結果をオブジェクトとして構造化してくれます。

実はこのHTMLパース、内部的にInternet Explorerのエンジンを呼び出すことで実現されています。（ちなみに後で説明しますが、-UseBasicParsingパラメータを付与すると、IEエンジンを使わずごく基本的なパースのみ行うようになります。）

Invoke-WebRequestコマンドレットの出力であるHtmlWebResponseObjectオブジェクトのParsedHtmlプロパティを経由することで、HTMLパースされたオブジェクトを、DOM（Document Object Model）に従ってアクセスすることができます。（-UseBasicParsing指定時は不可）

HTMLのtable要素を切り出し、table各行を1オブジェクト、各セルをプロパティとして、オブジェクト配列化する例を以下に示します。

$response = Invoke-WebRequest http://winscript.jp/powershell/301

# DOMを利用して1つ目のtable要素を取得
$table = $response.ParsedHtml.getElementsByTagName("table")| select -First 1

# tableの1行目をプロパティ名として取得
$properties = ($table.rows| select -first 1).Cells| foreach {$_.innerText}

# tableの残りの行に対して、各セルのinnerTextをプロパティ値としてオブジェクト化
$objs = foreach($row in ($table.rows| select -skip 1))
{
    $row.Cells| foreach -Begin {
        $index = 0
        $obj = [ordered]@{}
    } -Process {
        $obj += @{$properties[$index] = $_.innerText}
        $index++
    } -End {
        [pscustomobject]$obj
    }
}

$objs| Format-List

ところで前編で軽く触れましたが、IEエンジンによるパースは、Invoke-WebRequestコマンドレットを用いずとも、以下のようにして直接IEのCOMインターフェースを呼ぶことで利用可能です。

$client = New-Object System.Net.WebClient
$content = $client.DownloadString("http://winscript.jp/powershell/301")
$parsedHtml = New-Object -com "HTMLFILE"
$parsedHtml.IHTMLDocument2_write($content)
$parsedHtml.Close()
$table = $parsedHtml.getElementsByTagName("table")| select -First 1
# 以下同様…

というより実際に試すと直接IEエンジンを呼び出す方がずっと速いです。理由はよく分かりませんが…。

HTML要素コレクションの取得

Invoke-WebRequestコマンドレットを用いると、DOMとは別に、すべての要素（AllElementsプロパティ）、input要素（InputFieldsプロパティ）、img要素（Imagesプロパティ）、a要素（Linksプロパティ）、script要素（Scriptsプロパティ）を含むコレクションを、HtmlWebResponseObjectオブジェクトの対応するプロパティからそれぞれ取得することができます。

コレクションに含まれる各要素は、innerText（タグ内の文字列）、innerHTML（タグ内のHTML）、tagName（タグ名）等のプロパティが共通して利用可能です。また要素の属性（たとえばa要素ならリンク先を示すhref属性）に、プロパティとしてアクセス可能となります。

以下はBingでWeb検索した結果から、ページタイトルとURLを抜き出す例です。HtmlWebResponseObjectのLinksプロパティでa要素の配列を取ってきて、次に検索結果では無いっぽいURLを、hrefプロパティの値を見てwhereで除外し、最後にinnerTextプロパティとhrefプロパティをTitle、Urlとリネームしてから値を出力しています。泥臭い処理が混じってますが、この泥臭さがスクレイピングなのかもなぁと思います。

$searchWord = "PowerShell 配列"
$notSearchResults = "/","#","javascript:","http://go.microsoft.com/"
$response = Invoke-WebRequest "https://www.bing.com/search?q=$([Uri]::EscapeDataString($searchWord))"
$response.Links | 
    where {
        $href = $_.href
        !($notSearchResults|? {$href.StartsWith($_)})
    }|
    select @{L = "Title"; E = "innerText"}, @{L = "Url"; E = "href"}|
    Format-List

form要素についてもほぼ同様にFormsプロパティからコレクションを取得できますが、このコレクションにはFormObjectという特別なオブジェクトが含まれます。FormObjectのFieldsプロパティは、Key=パラメータ名、Value=パラメータ値が格納された連想配列となっています。この連想配列は書き替えが可能なので、前編で説明した、ログオンを要するWebサイト等で用いると便利かと思います。

以下に、HtmlWebResponseObjectオブジェクトのプロパティをまとめます。（×印は使用不可を表す）

プロパティ名	説明	-UseBasicParsing 指定時
AllElements	本文に含まれるすべての要素のコレクション	×
Forms	フォーム(form要素)のコレクション	×
InputFields	入力フィールド（input要素）のコレクション
Images	画像(img要素)のコレクション
Links	リンク(a要素)のコレクション
Scripts	スクリプト(script要素)のコレクション	×

このように、一部のプロパティについては-UseBasicParsing指定時でも利用可能です。サーバーOS等でIEエンジンが利用できない場合には-UseBasicParsingパラメータが必須となりますが、その場合でも最低限のパースはしてくれるわけです。

HTML要素のコレクションを利用する方法は、DOMを使う方法に比べると自由度は少ないですが、「ページから画像のリストを取得したい」等の処理は簡便に行うことができます。

その他のHTMLパース手法

最後に、Invoke-WebRequestコマンドレットとIEエンジン以外のHTMLパース手法について軽くご紹介します。

XMLとしてパース（XHTML限定）

XHTMLというのはごくかいつまんで言うと、HTMLをXMLで定義したものです。XHTMLはXMLなので、XMLとしてパースして用いることができます。

PowerShellは[xml]（XmlDocument）型アクセラレータと型アダプタにより、XML要素への簡便なアクセス手段を提供しています。以下のように、[xml]型アクセラレータを用い、取得したXHTML文字列を[xml]型に変換すると、以降は型アダプタの機能により、ドット演算子で要素を辿っていくことができます。

$client = New-Object System.Net.WebClient
$content = $client.DownloadString("XHTMLなページ")
$xml = [xml]$content
$xml.html.body.h2.'#text'

ただ世の中のWebページ上のXHTML文書が、すべてXML文書としてvalidなものであるかと言われると、現実はかなり厳しいです。そしてXML文書としてエラーがある場合は、型アクセラレータの処理は容赦なく失敗します。なのでこの手法は「使えたら強いが、大抵使えない」レベルのものと思って頂ければいいと思います。

SgmlReader

標準機能にこだわらなければ、.NET製のHTMLパーサーを使うのが楽かと思います。SgmlReaderは通常のHTML文書（当然、XHTMLに限らず）をXmlDocumentへとパースしてくれるので、PowerShellと相性が良いのではないかと思います。

以下にサンプルを載せておきます。

Add-Type -Path .\SgmlReaderDll.dll

function Get-HTMLDocument
{
    param([uri]$Uri)
    $sgmlReader = New-Object Sgml.SgmlReader -Property @{
        Href = $Uri.AbsoluteUri
        CaseFolding = [Sgml.CaseFolding]::ToLower
    }
    $doc = New-Object System.Xml.XmlDocument
    $doc.Load($sgmlReader)
    $doc
}

$xml = Get-HTMLDocument http://winscript.jp/
$xml.html.body.div|? id -eq outer|% div|? id -eq main|% {$_.p.innerText}

ぎたぱそ氏も以前SgmlReaderを取り上げておられるので、そちらも参考にして下さい。：Html Agility Pack と SgmlReader を使って PowerShell でスクレイピングしてみる - tech.guitarrapc.cóm

正規表現等で自前パース

これまではHTMLパースを既存のコマンドやライブラリを用いて行ってきましたが、対象のHTMLが非常にシンプルである場合とか、HTMLですらなく単なるテキストの場合だとか、対象ページは分量が多いものの必要箇所はごくわずかで、かつピンポイントに取得可能な場合等々は、むしろ自前でパースするコードを書いた方が手っ取り早いこともあります。

例えばYAMAHAのルーターで、管理Webのシステム情報レポートからグローバルIPアドレスを取ってくる、みたいなことは、

$response = Invoke-WebRequest http://サーバー/detail/status.html -UseBasicParsing -Credential $credential
if($response.Content -match "PP IP Address Local\: (.+)\,")
{
    $ipAddress = $Matches[1]
}

のようなコードで十分かと思います。

ConvertFrom-String

これはまだ検証してないんですが、PowerShell5.0の新機能、Auto-Generated Example-Driven Parsingの実装であるConvertFrom-Stringコマンドレットを用いて、HTMLパースができないかな、と考えています。

ConvertFrom-Stringについては過去記事参照：[v5] Auto-Generated Example-Driven Parsing について - PowerShell Scripting Weblog

まとめ

前後編に渡って、PowerShellでのWebスクレイピングの手法について解説しました。スクレイピングはWeb APIが用意されていない場合の苦肉の策ですが、背に腹は代えられない場合というのは稀によくあると思います。そういうときに今回の記事が参考になれば幸いです。

次回あたりには、Web APIがちゃんと用意されてる場合に、PowerShellから利用する話をやろうかと思います。

2014/10/12

「PowerShellコマンドの書き方」セッション資料とデモ用コード公開（PowerShell勉強会#4＠大阪）

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/09

[Friendly] 任意ウィンドウのコントロールのテキストを読み書きするコマンドレット

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;
                }
            }
        }
    }
}

ビルド方法

Windows 8.1 SDK をインストールする。
Visual Studio 2010以降でC#のクラスライブラリを新規作成する。
C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0 にある.dllを参照設定する。
対象フレームワークを.NET 4.5、対象プラットフォームをx64にする。
上記のコードを貼り付ける。
NuGetでFriendlyおよびFriendly.Windowsを追加する。
ビルドする。

使用方法

上記をビルドして生成した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の機能をラップしたコマンドレット群をきちんと設計、実装して、モジュールとして公開したいですね！

2012/01/13

スリープ状態に移行する

Posted: 14:23:47 |

コンピュータの再起動はRestart-Computerコマンドレット、シャットダウンはStop-Computerコマンドレットを使えばできますが、（休止状態ではなく）スリープはどうやるんだろう？と疑問に思い調査しました。

COMコンポーネントのShell.ApplicationのSuspendメソッドを使う方法：
少なくともうちのWin7環境では使えませんでした（何も起こらない）。
shutdown.exeを使う方法：
/hオプションを使えば休止状態にはできるが、スリープはできない模様。
rundll32.exe powrprof.dll,SetSuspendStateを使う方法：
ハイブリッドスリープが有効である場合は休止状態になる。ちなみにネットでたまにみかける”rundll32.exe powrprof.dll,SetSuspendState Sleep”でスリープするというのは嘘tipsです。
参照：rundll32.exe powrprof.dll,SetSuspendState Sleepって大嘘は誰が言い出したん - xcaqhbajのメモ
WMIのWin32_OperatingSystemのWin32Shutdownメソッドを使う方法：
シャットダウン、再起動、ログオフはできますがスリープや休止状態はできないようです。

というわけであまり簡単にはいかないようです。

幸いPowerShell 2.0からはAdd-TypeコマンドレットによりC#やVBを介してP/Invokeができますので、これを利用してスリープを行うWin32APIを呼び出すことにしました。

$signature = @"
[DllImport("powrprof.dll")]
public static extern bool SetSuspendState(bool Hibernate,bool ForceCritical,bool DisableWakeEvent);
"@
$func = Add-Type -memberDefinition $signature -namespace "Win32Functions" -name "SetSuspendStateFunction" -passThru 
$func::SetSuspendState($false,$false,$false)

powrprof.dllに含まれるSetSuspendState関数をP/Invokeで呼び出してやります。引数のHibernateはTrueを指定すると休止状態、Falseを指定するとスリープになります。今回はスリープしたいので$falseを渡してやります。

あとで知ったのですがSystem.Windows.Forms.Application.SetSuspendState メソッドを使うのでもいいですね。こちらの場合はAdd-TypeコマンドレットでSystem.Windows.Formsを読み込むと利用できるかと思います。

Add-TypeコマンドレットのおかげでPowerShellからWin32APIを簡単に呼べるようになり、○○はWin32APIを使わないといけないから諦めよう、ということがなくなりました。WSH時代に比べると良くなったなーと思います。本当はなるべくならWin32APIを直接は使わずに片づけたいところですけども。

2010/01/10

[PSv2]モジュールの開発時に便利なビルドイベント

Posted: 17:36:35 |

こんなビルドイベントはいかがでしょうか？

copy "$(TargetPath)" C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSTweets\
start powershell -NoExit -command "Import-Module PSTweets"

PSプロバイダやコマンドレットが含まれるdll（PSモジュール）をモジュールフォルダにコピーし、モジュールを読み込んだ状態でPowerShellを起動してくれます。ただし、systemフォルダに書き込む手順があるのでVisual Studioは管理者権限で起動してください。

元記事：http://blogs.wankuma.com/mutaguchi/archive/2010/01/10/184828.aspx

2009/10/28

[PSTweet]TwitterクライアントPowerShellモジュールを作ろう！(1)

Posted: 22:22:20 |

というわけで、PowerShell 2.0が出ましたのでモジュールをなんか作ってみたいと思います。手ごろで最近熱いといえばやっぱりTwitterクライアントじゃないかなあと。というわけで題材はこれ。

設計的なもの

・PSプロバイダを実装することで実現

・よって、独自コマンドレットは必要最低限実装

・Get-ChildItemでタイムラインを表示

・タイムラインはTimeLineオブジェクトで表現

・発言はTweetオブジェクトとして表現

・TimeLineオブジェクトの中にTweetオブジェクトの配列が含まれる

・PSpathとしてはタイムラインの場合Twitter::Friendになり、発言の場合はTwitter::username\0000000とかになる

・Set-Locationでタイムライン移動（フレンドTL,リプライTL,DirectMessage,任意のユーザー）

・Get-Contentでタイムラインや発言を文字列として取得

・Invoke-Itemでブラウザを開く

・Remove-Itemで自分の発言削除

・New-Itemでポスト

・Set-ItemPropertyで発言をお気に入りに追加

・認証が必要な操作に関しては-credentialパラメータを使用。ただしデフォルト値はどこかに保持しておく

・ぱっと思いつく必要な独自コマンドレットはGet-FollowerとGet/New/Remove-Followingかな。返す値はTweetする人ということでTweeterクラスを作る

というわけで、非常にシンプルというか硬派なクライアントです。シェルでパイプラインを駆使してフィルターかけたりスクリプトを組んだり、ラッパーGUIを組んだり（！）すると色々楽しいと思います。

とりあえずモジュールのHello Worldまでメモ。

基本はPSスナップインを作るのと同じです。なので、詳細は

C#と諸々コマンドレットの作成方法
http://csharper.blog57.fc2.com/blog-entry-55.html

をご覧ください。ここでスナップインクラスを作る、インストール、スナップイン登録という部分をまるっきり省けばOKです。

配置ですが、$pshome\Modulesに今回作るクライアント名であるPSTweetフォルダを作ります。そこにPSTweet.dllとPSTweet.psd1を配置します。psd1ファイルはこんな感じで良いようです。

@{
GUID="{847D070F-3247-46AB-BAE9-166038EFEA4B}"
Author="Daisuke Mutaguchi"
CompanyName="Winscript"
Copyright="© Daisuke Mutaguchi. All rights reserved."
ModuleVersion="1.0.0.0"
PowerShellVersion="2.0"
CLRVersion="2.0"
NestedModules="PSTweet"
RequiredAssemblies=Join-Path $psScriptRoot "PSTweet.dll"
}

あとはImport-Module PSTweetでシェルから読み込めます。

というわけでこれから作っていこうと思いますよ。

元記事：http://blogs.wankuma.com/mutaguchi/archive/2009/10/28/182510.aspx

2007/11/08

EmEditor私のマクロその3 .vb .cs .jsのコンパイル実行

Posted: 17:02:00 |

.NETアプリをFramework付属のコンパイラを使ってコンパイルし、できあがった実行ファイルexeを実行するというものです。これがまた便利でｗ *.vbか*.csか*.jsファイルを開いた状態で、コメント行に記述したコンパイラに渡すオプション（VB.NETなら'/r:System.Windows.Forms.Dll /t:winexeという行の/r:System.Windows.Forms.Dll /t:winexeという部分）を選択すると、そのコンパイラオプションをつけてコンパイルします。デフォルトだと/t:exeが渡されます。

'*.cs, *.vb, *.jsをコンパイルして実行
Set regEX = New RegExp
regEx.Global = True
regEX.IgnoreCase = True
Set Fs = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("WScript.Shell")

sCompilerDir = "C:\windows\Microsoft.NET\Framework\v2.0.50727\"
sDefaultArguments = "/t:exe" 'winexe
sSourcePath = Document.FullName
sEXEPath = Fs.BuildPath(Fs.GetParentFolderName(sSourcePath),Fs.GetBaseName(sSourcePath) & ".exe") 
sExt = LCase(Fs.GetExtensionName(sSourcePath))

Document.Save sSourcePath 'ソース保存

Select Case sExt
	Case "vb" : sCompilerPath = sCompilerDir & "vbc.exe"
	Case "cs" : sCompilerPath = sCompilerDir & "csc.exe"
	Case "js" : sCompilerPath = sCompilerDir & "jsc.exe"
	Case Else : sCompilerPath = ""
End Select

Set sel = Document.Selection

If sel.IsEmpty Then
	sArguments = sDefaultArguments
Else
	regEx.Pattern = "\s?(\/[^\:]+\:\S+)\s?"
	If regEx.Test(sel.Text) Then
		For Each oMatch In regEx.Execute(sel.Text)
			sArguments = sArguments & oMatch.SubMatches(0) & " "
		Next
	Else
		sArguments = ""
	End If
End If

If sCompilerPath="" Then
	Alert sExt & "ファイルに対応するコンパイラがありません。"
Else
	sCommandLine = "cmd.exe /k " & sCompilerPath & " " & _
	"/out:" & """" & sEXEPath & """" & " " & sArguments & " " & _
	"""" & sSourcePath & """"
	WshShell.Run sCommandLine ,,True 'コンパイル実行
	If Fs.FileExists(sEXEPath) Then
		WshShell.Run sEXEPath,,True 'コンパイルしたファイルを実行
	Else
		Alert "コンパイルに失敗したようです。"
	End If
End If

元記事：http://blogs.wankuma.com/mutaguchi/archive/2007/11/08/106978.aspx

2007/07/10

最近はOLE/COM Object ViewerにIViewers.dllが付属してないのね

Posted: 23:46:00 |

Download details: Windows 2000 Resource Kit Tool : OLE/COM Object Viewer (oleview.exe)
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en

COMオブジェクトの仕様を調べるのに重宝するOLE/COM Object Viewerですが、最近ダウンロードサイトにあがってるインストーラには、動作に必須のIViewers.dllが含まれていませんね。どこで入手できるんでしょう？私がむかーしダウンロードしたときには付属してたんですがね・・・困りますねー。

元記事：http://blogs.wankuma.com/mutaguchi/archive/2007/07/10/84643.aspx

2006/11/07

dir /b に相当するコマンドは？

Posted: 01:12:00 |

cmd.exeでdir /bとすると、カレントにあるファイル名・ディレクトリ名だけを出力します。以下、例。

C:\WINDOWS\system32\windowspowershell\v1.0>dir /b
certificate.format.ps1xml
dotnettypes.format.ps1xml
examples
filesystem.format.ps1xml
help.format.ps1xml
ja
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

同じことをPowerShellにやらせるにはどうすればいいか、考えてみました。

【案1】

PS C:\WINDOWS\system32\WindowsPowerShell\v1.0> ls|format-wide -c 1

    ディレクトリ: Microsoft.PowerShell.Core\FileSystem::C:\WINDOWS\system32\Win
    dowsPowerShell\v1.0

[examples]
[ja]
certificate.format.ps1xml
dotnettypes.format.ps1xml
filesystem.format.ps1xml
help.format.ps1xml
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

Format-Wideコマンドレットを使った例。うーんちょっと違う。でもディレクトリに[]が付くのでわかりやすいかも。これはこれで。

【案2】

PS C:\WINDOWS\system32\WindowsPowerShell\v1.0> ls|select name
Name
----
examples
ja
certificate.format.ps1xml
dotnettypes.format.ps1xml
filesystem.format.ps1xml
help.format.ps1xml
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

Select-Objectコマンドレットを使ってNameプロパティだけをもったPSCustomObjectのArrayを作っているのでこんな感じに出力されます。
Name
----
が邪魔ですね。

【案3】

PS C:\WINDOWS\system32\WindowsPowerShell\v1.0> ls|%{$_.name}
examples
ja
certificate.format.ps1xml
dotnettypes.format.ps1xml
filesystem.format.ps1xml
help.format.ps1xml
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

これでdir /bと同じ結果になりました。Foreach-ObjectでNameプロパティだけを取り出して出力しているわけです。

【案4】

PS C:\WINDOWS\system32\WindowsPowerShell\v1.0> ls|split-path -leaf
examples
ja
certificate.format.ps1xml
dotnettypes.format.ps1xml
filesystem.format.ps1xml
help.format.ps1xml
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

Split-Pathコマンドレットを-leafオプション付きで使っても同様の出力が得られました。これ実は何故こうなるのかよくわからないんですけど、たぶんパイプを渡るときに、System.IO.DirectoryInfoオブジェクトやSystem.IO.FileInfoオブジェクトのNameプロパティが渡されてるか、ToString()メソッドが実行されているのでしょうね。ps1xmlファイルの何らかの記述でこうなっているのかもしれません。でもまあ仕組みが分からなくてもこの動作は非常に合理的であります。

【案5】

PS C:\WINDOWS\system32\WindowsPowerShell\v1.0> ls -name
examples
ja
certificate.format.ps1xml
dotnettypes.format.ps1xml
filesystem.format.ps1xml
help.format.ps1xml
powershell.exe
powershellcore.format.ps1xml
powershelltrace.format.ps1xml
pwrshmsg.dll
pwrshsip.dll
registry.format.ps1xml
types.ps1xml

ていうかこんなことをしなくても、Get-ChildItemコマンドレットには-nameオプションがあり、dir /bと同じ効果が得られるのでした。ヘルプの見落としでこんな回りくどいことを考えていたのです。すみません、こんなオチで。でもまあ同じことをやるのに色んな手段があるということが分かったので良しとしましょう。

元記事：http://blogs.wankuma.com/mutaguchi/archive/2006/11/07/43902.aspx

古い記事のページへ |

Pick Up

Article List

Keywords

2017/12/10

プレーンテキスト

書き出し

追記

読み込み

メリット

デメリット

CSV

書き出し

追記

読み込み

メリット

デメリット

JSON

書き出し

読み込み

メリット

デメリット

CLIXML

書き出し

読み込み

メリット

デメリット

psd1

書き出し

読み込み

メリット

デメリット

まとめ

2015/12/10

はじめに

IEエンジンによるHTMLパース（DOM）

HTML要素コレクションの取得

その他のHTMLパース手法

XMLとしてパース（XHTML限定）

SgmlReader

正規表現等で自前パース

ConvertFrom-String

まとめ

2014/10/12

2014/09/09

コード

ビルド方法

使用方法

制限事項

今後の方針？

システム管理方面では…

開発方面では…

2012/01/13

2010/01/10

2009/10/28

2007/11/08

2007/07/10

2006/11/07

Twitter

Books