2016/12/12

この記事はPowerShell Advent Calendar 2016の11日目です。遅刻してごめんなさい!

ASTとは

ASTとはAbstract Syntax Treeの略で、日本語では「抽象構文木」といいます。コードをパーサーが構文解析した結果から、言語の意味に関係のない要素(空白等)を除外し、木構造として構築したものです。

PowerShellでは3.0からASTの仕組みが取り入れられました。スクリプト実行時にはまずパーサーがスクリプトブロックからASTを生成し、コンパイラによってASTが解釈され、実行されるようになっています。

ASTを直接的に扱うのはコンパイラですが、実はPowerShellではパーサーが構築したASTを、PowerShellスクリプトから扱うことができます。

ASTの具体的な使い道としては、構文の静的解析が挙げられますが、その話は後でするとして、今回はまず、ASTの構成要素と構造を見ていきます。

ASTの構成要素

具体的には、{スクリプトブロック}.Astとして、ScriptblockオブジェクトのAstプロパティから、ScriptBlockAstオブジェクトにアクセスできます。このオブジェクトがASTのルートとなるノード(分岐点)を表します。このScriptBlockAstから、スクリプトブロック内部の構文要素が木構造として展開されていきます。

式(Expression)、文(Statement)といった構文要素は、各々対応したAstクラスが対応し、木構造における分岐点を形成します。また、分岐点の末端の葉では、当該の構文要素を構成するデータを示すオブジェクトが格納されます。

すべてのAstクラスは、Ast抽象クラス(System.Management.Automation.Language.Ast)を継承したクラスです。PowerShellでは50個程のAstクラスが存在します。各Astクラスは、抽象クラスで定義されている以下の2つのプロパティを持っています。

  • Parent
    親ノードを示すAstオブジェクトを返す
  • Extent
    当該のASTノードに含まれるコード文字列や、スクリプト全体から見たコード文字列の位置等の情報を持つ、IScriptExtentインターフェースを実装したクラスのオブジェクトを返す

また各Astクラスは、対象の構文要素に応じて、それぞれ異なったプロパティを持ちます。たとえばScriptBlockAstは以下のプロパティを持ちます。

子の分岐点を返すもの

  • UsingStatements
    Using節を表す、UsingStatementAstのコレクションを返す
  • Attributes
    スクリプトブロックに付与された属性を表す、AttributeAstのコレクションを返す
  • ParamBlock
    paramブロックを表す、ParamBlockAstを返す
  • BeginBlock、ProcessBlock、EndBlock、DynamicParamBlock
    各々、beginブロック、processブロック、endブロック、DynamicParamブロックを示すNamedBlockAstを返す

葉を返すもの

  • ScriptRequirements
    #Requires節の内容を表す、ScriptRequirementsを返す
ASTの構造

たとえば、

$scriptBlock = {
    param([int]$x,[int]$y)
    end
    {
        $out = $x + $y
        $out | Write-Host -ForegroundColor Red
    }
}

という、二つの整数値の和を赤字で表示するというスクリプトブロックならば、以下のようなASTが構築されます。(一部分岐点、葉は省略しています。また、分岐点のASTクラス名は、末尾の"Ast"を省略表記しています。)

PowerShell_AST

このスクリプトブロックのASTから、例えば「Red」というパラメータ値を表す、StringConstantExpressionAstまで辿るには、

$scriptBlock.Ast.EndBlock.Statements[1].PipelineElements[1].CommandElements[2]
StringConstantType : BareWord
Value              : Red
StaticType         : System.String
Extent             : Red
Parent             : Write-Host -ForegroundColor Red

のようにします。

基本的なASTの構造が頭に入っていれば、タブ補完を併用することで比較的簡単に目的のノードまで辿れますが、ASTノードの子に対し、ノード検索をかける方法もあります。

例えば、すべてのVariableExpressionAstを列挙するには、

$scriptBlock.Ast.FindAll({
    param($ast)
    $ast -is [System.Management.Automation.Language.VariableExpressionAst]
}, $true)

のように、FindAllメソッドを用います。

AST編はあと何回か続く予定です。

2016/12/01

この記事はPowerShell Advent Calendar 2016の1日目です。

PowerShellアドベントカレンダー、今年も始まりました。みなさまのご協力の甲斐あって、過去5年間はすべて完走していますが、今回もできれば完走を目指していく感じでまいりましょう。色々な立場の方からの視点でPowerShellを俯瞰できるこのイベント、私自身も毎年楽しんでおります。

さて、去年も2015年のPowerShellをまとめる的な記事から始めたわけですが、今年も去年に負けず劣らず、大変革の年だったと思いますので、今回も1年を振り返るところからスタートしましょう。

Bash on Ubuntu on Windows の登場

去年のPowerShell5.0登場、周辺モジュールのOSS化といった大きな動きがあってから、今年の前半は少しおとなしめ?の界隈でした(5.0のインストーラーにバグがあって一時非公開とか小騒動はありました)が、まず驚いたのがPowerShellそのものではなくて、Windowsで動くbashが登場したというトピックですね。発表があったのは今年の3月末の事です。

bashとは言わずと知れた、Linuxの標準シェルですが、これをWindows 10の"Windows Subsystem for Linux"という仕組みの上で動作するUbuntu上で動作するbashとして動作させてしまおうというものです。なので正式には"Bash on Ubuntu on Windows"という名称になります。

このbash、Windowsのシステムを管理するためのものではなく、Web等の開発用途を想定して提供されたものです。なので本来的にはPowerShellとは関係ないのですが、当初は色々と誤解が飛び交ったように思います。曰く、MSはPowerShellを捨ててやっとbashを採用した。PowerShellとは何だったのか。等々…。

これらの誤解や疑問には、PowerShellの公式ブログで、bashという新たなシェルがWindowsに追加されたが、両者は並立するものだ、PowerShellはこれからも進化するよ!といった異例の公式見解が示されたりもしました。

Bash on Ubuntu on Windowsは、後述するPowerShell 5.1とともに、8月リリースのWindows 10 Anniversary Updateで正式に利用可能となりました。

PowerShell 5.1 の登場

今年7月には、PowerShell 5.1 / WMF (Windows Management Framework 5.1)のプレビュー版が登場しました。[リリースノート]

そもそもPowerShell 5.0はWindows Server 2016のためのシェルとして開発が進められていたはずですが、先にWindows 10に同梱されたものの、2016正式版までやや時間を要すこととなりました。その間にPowerShell 5.0にはいくつかの機能や改良が加えられ、結局、5.1というバージョンが登場するに至ったものと思われます。

PowerShell 5.1は、前述の下位OS用のプレビュー版の他、今年8月初めのWindows 10 Anniversary Updateという大型アップデート適用で使えるようになりました。そしてその後、今年10月に正式版が登場したWindows Server 2016にも(もちろん)同梱されました。

5.1ではローカルユーザーやグループを扱うコマンドレット等が(ようやく?)追加されたりもしています。が、一番大きな変更点は、Windows Server 2016に追加された新機能である、Nano Server用のPowerShellが、従来のPowerShellと分離した点でしょう。

従来の、.NET Frameworkで動くフル機能のPowerShellは、5.1からは"Desktop Edition"と呼ばれます。対して、コンテナに最適化させるため、フットプリントを最小にしたNano Server(や、Windows IoT等)で動作するコンパクトなサブセット、"Core Edition"が新たに登場しました。

Core Editionは、.NET Frameworkのコア部分を実装した、.NET Core上で動作します。ちなみに.NET CoreはOSS(オープンソースソフトウェア)となっています。

Core Editionはサブセット版というだけあって、今となっては若干レガシーにもなった一部のコマンドレットが使えないことを初め、いくつかの制限事項もありますが、概ね、Nano Serverの管理に必要十分な機能を保っているのではないかと個人的には思っています。

PowerShell オープンソース化

今年、PowerShell界をもっとも震撼させたニュース、それは間違いなく、今年8月に実施された、PowerShellのオープンソース化でしょう[GitHub]。周辺モジュールのOSS化など、これまでの流れからいくと、確かに本体OSS化の機運は高まっているように個人的にも感じていましたが、OSS化するとしてもCore Edition部分止まりだろうなーと思っていたら、まさかのDesktop Editionを含んだ全体だったので驚きました。

そしてOSS化の副産物(と個人的には感じる)である、PowerShell on Linux、PowerShell on Macが登場しました。これも一部の方、特にWindowsやMicrosoft製品を普段あまり使われない方に、割と大きなインパクトを与えていたように思います。

PowerShellがオープンソースになったこと、"PowerShell for every system!"になったことの意義についてはちょっと語りつくすには時間が足り無さそうですが、敢えて現実ベースの話を先にすると、一般ユーザー(PowerShellをシステム管理に用いている管理者)にとって、すぐに世界が変化するかというとそうではないんじゃないかという気がしています。

というのも、現在のところOSS版のPowerShellのバージョンは「6.0」とされているものの、まだα版の段階で、基本機能はほぼほぼ5.1と変わらないです。OSS版が改良されても、別に今Windowsで使っているPowerShellがすぐに強くなるわけではありません(現在のところ、サイドバイサイドでインストールする)。オープンソース、マルチプラットフォーム展開を始めたといっても、それは現在の所、PowerShell本体とコアモジュールに留まっていて、コマンド数もたかだか数百個程度でしょう(もうちょっとあるかな?)。PowerShellでOS、サーバー、アプリ、インフラを管理するには、専用のコマンドが山ほど必要になってきますが、それらは今まで通り、Windowsの製品にしか含まれないものです。そのような状況で、たとえばLinuxを管理するのには自分でコマンドを作るか、普通にLinuxのコマンドを呼ぶか…あれそれって別に普通のシェルスクリプトでいいんじゃ…とか。

今後は、OSS側での成果が、Windows / Windows Server上のPowerShellに反映され、両者は一本化される、はず、です、たぶん、が、それはまだアナウンスもなく、いつ、どのような形でもたらされるかは不明と云わざるを得ません。

もちろん、この状況はあくまで現時点の状況です。ゆくゆくはPowerShellで、WindowsもLinuxもMacも一貫したコマンド&スクリプトで管理できる日が来るかもしれませんね。現在のところは、PowerShellの謎挙動に遭遇したとき、ソースを合法的に眺めて思いを馳せることができるようになったのが大きいかと個人的には思います。もちろん腕に覚えのある方は、(ルールに従って)どしどしプルリクエストを投げて、PowerShellを自ら育てていただければな、と思います。

PowerShell 10周年

とまぁ、激動の1年が終わりかけた先日の11/14には、PowerShell 1.0が登場してちょうど10年ということで、PowerShell10周年イベントがあったりしました。思えば遠くへ来たものですね。

さてさて、PowerShellを取り巻く状況は刻一刻と変化し、去年と今年ではその傾向が顕著です。おそらく節目の年である今年の最後を飾ることになる、PowerShell Advent Calendar 2016を、どうぞよろしくお願い致します。

2011/09/30

いきなりですが、PowerShellで「カレントディレクトリに含まれる.txtファイルの拡張子をすべて.logに変更する」方法がぱっと思いつくでしょうか?

コマンドプロンプトなら

ren *.txt *.log

で一発なのですが、PowerShellでrenコマンドに対応するコマンドレットであるRename-Itemコマンドレットを使って

Rename-Item -path *.txt -newName *.log

と書くことはできません。Rename-Itemコマンドレットの-pathパラメータと-newNameパラメータはワイルドカード文字を受け付けないからです。

ではどう書くのか。Get-ChildItemコマンドレットの-pathパラメータはワイルドカード文字を使うことができます(Get-Help Get-ChildItem -fullを調べるとpathパラメータの「ワイルドカード文字を許可する」はfalseになってますが、実際はワイルドカードが使えます)。よってGet-ChildItemでワイルドカードを用いてファイル一覧を取得し、それをRename-Itemコマンドレットにパイプで渡すとよさそうです。Rename-Itemの-pathパラメータは「パイプライン入力を許可する true (ByValue, ByPropertyName)」なので、パイプ経由でオブジェクトを渡すとこのパラメータに値が渡ります。なお、ByValueなどの意味は以前書いたエントリを参考にしてください。では書いてみましょう。

Get-ChildItem *.txt | Rename-Item -newItem *.log

あれ、新しい名前のほうのワイルドカードはどうすればいいんだ?というわけでこれでは駄目で、まだ一工夫が必要です。

素直に考えると、Get-ChildItemの結果(FileInfoオブジェクトの配列)をForEach-Objectで列挙して、その各要素でNameプロパティを元にRename-Itemコマンドレットを実行するというのが思いつきます。

Get-ChildItem *.txt | %{Rename-Item -path $_.Name -newName ($_.Name -replace "\.txt`$",".log")}

注: -replace演算子の右辺配列の最初の要素は正規表現を指定します。なので正規表現における特殊文字「.」は「\」でエスケープする必要があります。さらに拡張子以外の文字が置き換わらないように文字列の末端を表す「$」を使用します。「$」はPowerShellにおいて特殊文字なので「`」でエスケープします。

しかしこれはなんかNameプロパティの値を2回も参照してて冗長ですしあまりやりたくないですね。そもそもせっかくRename-Itemコマンドレットの-pathパラメータにパイプライン経由で直接オブジェクトを流し込める利点を生かせていません。

そこで登場するのが、このエントリのタイトルにもある「スクリプトブロックパラメータ」です。実はPowerShellには任意のコマンドレットパラメータにスクリプトブロックを指定する機能があるのです。コマンドレットパラメータは型が指定されていますが、これが<scriptblock>である必要はなく、<string>でも<int>でも何でもOKです。したがって、冒頭の問題の回答は次のように記述することができます。

Get-ChildItem *.txt | Rename-Item -newName {$_.Name -replace "\.txt`$",".log"}

このように、-newNameパラメータの型は<string>であるにも関わらず、スクリプトブロックを指定することができるのです。このスクリプトブロック内の$_は、パイプラインに渡されたオブジェクト配列の一要素です。つまりここではFileInfoオブジェクトになります。

注:この例だとファイルはカレントディレクトリにあるものが対象になるので、カレントディレクトリ以外で実行する場合はNameプロパティの代わりにFullNameプロパティを使ってフルパスを指定してください。

この機能、マイナーだと思いますが知っているとずいぶん楽になるケースが多いと思うので、ぜひ覚えておくことをお勧めします。しかし実はこの例題、Rename-Itemコマンドレットのヘルプの例4そのままだったりします。私はそこの解説を読んでもいまいち仕組みが分かりませんでした。Flexible pipelining with ScriptBlock Parameters - Windows PowerShell Blog - Site Home - MSDN Blogsという記事を読んでようやくこれがPowerShellの機能だと認識した次第です。

まあ、それでもrenコマンドのお手軽さには負けますけども、柔軟性に関してはもちろんPowerShellのほうが圧倒的に優れているのでそこは我慢するしかないのかなあ、と思います。どうしても簡単に書きたい場合は

cmd /c ren *.txt *.log

とかしてくださいませ。

ちなみにこの機能はユーザーが定義した関数では原則使用できないようです。ただ例外があって、次のような関数定義をしておくと大丈夫でした。

function test
{
    param([parameter(ValueFromPipeline=$true)][string]$str)
    process
    {
        $str
    }
}

ポイントはパラメータにparameter属性を指定して、ValueFromPipelineもしくはValueFromPipelineByPropertyNameを$trueにすることと、型名を指定すること(ここでは<string>)です。こうしておけば

dir|test -str {$_.fullname}

のようにして、コマンドレットの場合と同様にスクリプトブロックパラメータを使うことができます。属性と型指定どちらかが欠けているとスクリプトブロックが展開されずそのまま-strパラメータに渡ってしまうようです。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2011/09/30/203768.aspx

2011/05/04

PSプロバイダをC#で実装する場合、NavigationCmdletProviderクラスなんかを継承させたクラスを作ってCmdletProvider属性をつけてやりますが、今回はその辺の話は省略して、このクラスからPowerShell変数を読み書きする方法について述べます。

たとえばそのPSプロバイダを含むモジュールを読み込んだPowerShellコンソールに変数$valを書き出すには、

this.SessionState.PSVariable.Set("val", 1);

のようにします。

逆にコンソールで読み込まれている変数$valの値を読み込むには、

PSVariable ret = this.SessionState.PSVariable.Get("val");

のようにします。

と、それだけなら話は簡単なのですが、実はPowerShellの仕組み上、そう単純には行きません。書き出しの方はさほど問題はないのですが、問題は読み込み。ここでretに格納されたオブジェクトから$valの実際の値を取得するにはどうすればいいでしょうか。

このコードを上から順に実行したら、ret.Valueにその値が入っているので、これを単にintにキャストすればOKです。

しかし$valがPowerShell側でその値が変更されていた場合は、ret.ValueにはPSObjectという、元の値をラッピングしたオブジェクトが格納されています。実際の値はPSObject.BaseObjectに格納されています。よって、(int)((PSObject)ret.Value).BaseObjectのように取得する必要があります。

めんどくさいのでメソッドにしてしまいました。

private T GetPSVariableValue<T>(string name)
{
    PSVariable variable = this.SessionState.PSVariable.Get(name);
    if (variable != null)
    {
        T obj;
        if (variable.Value is PSObject)
        {
            obj = (T)((PSObject)variable.Value).BaseObject;
        }
        else
        {
            obj = (T)variable.Value;
        }
        return obj;
    }
    else
    {
        return default(T);
    }
}

使い方は

int ret = GetPSVariableValue<int>("val");

みたいな感じです。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2011/05/04/198782.aspx

2010/05/20

PowerShell的システム管理入門
第3回 ファイル/レジストリの操作

http://www.atmarkit.co.jp/fwin2k/operation/pshsys03/pshsys03_01.html

よろしくお願いしますー。

ファイル、フォルダ操作、テキストファイル読み書き、レジストリ操作などの話題です。PSプロバイダという仕組みに基づいていろいろなリソースを同じコマンドレットで扱えるところがポイントですね。

そして5/29のわんくま大阪勉強会でPowerShellのコマンドレットとPSプロバイダを開発する話をやります。ファイル、レジストリ、Active Directory、そしてTwitter…。ご興味のある方はぜひご参加ください!

元記事:http://blogs.wankuma.com/mutaguchi/archive/2010/05/20/189218.aspx

2009/12/03

TwitterはRESTなAPIを備えているので、httpの通信ができれば基本的にどんな言語でもクライアントを作ることができるのがいいです。そこで私もPSTweetsというPowerShell版Twitterクライアントを作っているのですが、認証周りで問題が発生しています。

Twitterの認証には標準認証とOAuthが使えるのですが、現在はセキュリティ上の理由で標準認証は非推奨です。標準認証がなぜまずいかというと、マッシュアップサービスでTwitterに対して認証が必要な操作をする場合、ユーザーがその第三者のサービスにTwitterのIDとパスワードを送らなければならないためです。そのサービスがユーザーの認証情報を安全に保持してくれる保証はありません。

そこで考えられたのがOAuthという認証方法です。OAuthはとてもややこしいプロセスを含んでいますが、実質はそんなに難しいものではないです。要は、Twitterというサービス(これをサービスプロバイダという)にアクセスするための権限を、マッシュアップやクライアントを提供する第三者(これをコンシューマという)に委譲する仕組みです。ユーザーが「コンシューマを使いたい!」と思ったら、コンシューマは「じゃあついったーのページに飛ばしますから、あなたのアカウントを私が自由に使うことを許可してね」と言います。それでユーザーがTwitterのOAuth承認ページで「許可」すると、コンシューマはユーザーのアカウント情報を使ってTwitterのAPIを叩けるようになり、ユーザーはコンシューマにTwitterのパスワードを知らせることなくコンシューマの提供するサービスを利用することができるわけです。

さて、このOAuthをコンシューマが利用するには、Twitterにあらかじめ申請する必要があります。といっても登録ページでクライアント/サービス名などを入力するだけです。そうすると、コンシューマキーとコンシューマシークレットという文字列をもらえます。これはクライアントを特定するためのユーザー名とパスワードみたいなものです。ちなみにこの情報はコンシューマを提供する人のTwitterのユーザーアカウントに紐づいています。

コンシューマを通じてユーザーがTwitterのサービスを使うには、コンシューマを通じてTwitterからアクセストークンというものを貰う必要があります。このとき、コンシューマはTwitterに毎回コンシューマキーとコンシューマシークレットを送らなければなりません。

ここでコンシューマが独立したサーバーで運営されているサービスならば何も問題ありません。ユーザーがコンシューマキーとコンシューマシークレットを知る必要もユーザーに知られる危険性もありません。ところが、デスクトップクライアントだとどうなるかというと、コンシューマはデスクトップクライアントそのものです。なので、デスクトップクライアントはコンシューマキーとシークレットを何らかの方法で取得し、Twitterに送る機構が必要になります。

ここで、いくつかの方法があると思います。コンシューマキーとシークレットをデスクトップクライアントに暗号化して埋め込むのも一つの方法でしょう。ですが、結局は復号してTwitterに送らなければならないので、その通信をキャプチャすればユーザーは知ることができます。

なぜコンシューマキーとシークレットをユーザーに知られるとまずいかというと、それらを使うとまったく別のクライアントやサービスを、そのサービス名を詐称して作ることができてしまうからです。これがどうして問題なのかというと、そうなるとOAuthの承認が有名無実化してしまうためです。ユーザーがOAuthの承認ページで承認するサービスが本物かどうか調べるすべがありません。

メール登録制にしてコンシューマキーとシークレットを配布するとか考えましたが、なんだか大昔のシェアウェアのようで、なんとかシリアル集がはびこったように誰かが漏らしてしまう危険性を考えると難しいです。

コンシューマキーとシークレットを自分で取得してもらうというのも考えましたが、それはユーザーにとってかなり敷居が高いうえ、クライアント名がみんなバラバラになってしまいます(Twitterクライアント名はユニークであるため)。

コンシューマキーとシークレットを保持し、ユーザーからのリクエストに応じてアクセストークンを発行するサーバーを立てるというのも考えましたが、それってもうデスクトップTwitterクライアントじゃなくて、Twitterマッシュアップのデスクトップクライアントになってしまいます。

なので、デスクトップクライアントでOAuthを使うのは事実上無理なんじゃないかというのが私の結論です。

標準認証でもいいんですが、現在は標準認証は非推奨であり、そのため今からクライアントを作る場合は標準認証だとクライアント名をTwitterに登録することができなくなっています(タイムラインには「APIで」という表示になってしまう)。昔はメールでクライアント名を申請できたんですが、今はできません(この体制になる前に申請されたクライアントなら、今でも標準認証でもクライアント名を名乗れます)。これから作るクライアントで、クライアント名を名乗るにはOAuth必須です。ボット作者など、コンシューマ=ユーザーの場合はそれでもいいんですが…。これはぜひなんとか改善してもらいたいところですね。といっても、Twitter側からみると、それがコンシューマからのアクセスなのか、ユーザーからのアクセスなのか、区別をするのは難しいでしょうから、デスクトップアプリに限り標準認証でもクライアント名を名乗れるようにする、というのは難しいんじゃないかという気はします。

最近、新しいデスクトップクライアントがあまり登場せず、一方でやたらTwitterのマッシュアップサイトが増えたと思いませんか?中には、それデスクトップアプリでいいじゃないというものもちらほら。もしかして、この制限ができたためなんじゃないかと邪推までしています。うーむ、なんとかならないですかねー?

元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/12/03/183506.aspx

2007/06/17

わんくま同盟 大阪勉強会 #10
http://www.wankuma.com/seminar/20070623osaka10/

  • 11:30〜11:40 わんくまについて
  • 11:40〜12:30 「DSLとは? DSLシリーズ第1回」 by 中博俊 Lv 2
  • 13:30〜14:30 「SQL Server Integration Services DSLシリーズ第2回」 by 中博俊 Lv 2
  • 14:45〜16:00 「Hello, "Hello, world!" world!」 by とりこびと Lv 2
  • 16:15〜17:45 「Internal ASP.NET」 by 囚人 Lv 3
  • という内容で勉強会があります。

    DSLってなんだろう?って思ってちょっと調べてみたんですが(WikiPediaMicrosoft)、要するに、ある対象(ドメイン)に特化した言語を作ろう、という話なのかな?と思いました。スクリプト言語もDSLに近い概念であるらしいし私の守備範囲かもしれませんので是非聞いておこうと思いました。

    とりこびとさんのセッションは、例題ではHello Worldってよくやるけど、なんでHello Worldが出力されるんだ、その仕組みはどうなんだ、ということを特定言語に問わずやるっぽいですね。これも面白そう。

    囚人さんのは題名とレベルからASP.NETの内部的な濃い話が聞けるんじゃないかと思います。ちょっとついていくのがつらそうですが頑張ってついていこうと思います。

    そんな感じで。お近くの方はぜひどうぞ。私も今回は参戦しますよー。

    元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/06/17/81011.aspx

    2007/01/15

    スクリプト センターの新着記事にこんなのが。

    VBScript からも .NET Framework のクラスを利用できる?!
    NET Framework のクラスは VBScript からアクセスできないと皆さん思っていませんか? 後悔する前にこの記事を読みましょう!

    System.Collections.ArrayListなんかを普通にCreateObjectして使えるんですねー。

    しらんかったー!すげー!

    たしかにProgIDがレジストリに登録されてるから、使えるような気はしてましたが、まさか本当に使えるとは。

    これってどういう仕組みなんだろう?どのクラスが使えてどのクラスがだめかは筆者も調査中とのことですが、相当いろんなことができるんじゃないでしょうか。

    少なくともCOMコンポーネントにはコンストラクタがない(ですよね?)のでコンストラクタが必須のクラスは駄目でしょうね。

    まだまだWSHいけるんじゃないですか?PowerShellもいいですけどWSHも使いましょう。

    元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/01/15/56349.aspx

    2006/12/18

    12/16、わんくま大阪勉強会#4でPowerShellのセッションをさせていただきました。
    いろいろと拙いところがありましたが、ご静聴いただきありがとうございました。

    いくつかフィードバックやご質問をいただきました。

    ・PPTに書いてること以外をしゃべってほしい
    →資料だけを読まれる方のためにPPTだけを見ても分かるようにしたのですが、せっかく参加された方のためにもそれ以外のことをしゃべったほうがいいですね。今回は時間がなくてなかなか難しかったのですが次回は改善させていただきたいです。

    ・デモが少ないので増やしてほしい
    →これも時間の関係で今回ちょっとしかやれなかったのですが、次回1/12(金)はたっぷりやれると思います。シェルを叩くだけでなくスクリプトをその場で書いていくのもいいですね(今回他の方のセッションを見て思ったのですが)。ネタを仕込んでおかなければ…。

    ・実際に使える実用的なスクリプトサンプルが見たい
    →時間の関係でスクリプトに関してはほとんど取り上げられなかったのですが、これも次回きちっとやります。PowerShellならではのスクリプトを鋭意研究中です。あまり運用系のことがわからないので、「こんなスクリプトがあったら嬉しい」などのご意見をお待ちしております。メールやここのコメント欄などでいただきたいと思います。

    ・IronPythonとの住み分けは?
    →申し訳ありませんが、まだIronPythonを弄るところまでは行っていません。おいおい、研究していきたいと思います。現時点では個人的にはPowerShellは運用系、IronPythonは開発系なのかなと思います。

    ・安定性は?
    →少し重いというのがありますが、安定性はまずまずなんじゃないでしょうか。

    ・仕組みは?
    →現時点では正直なところ、なぜ動作するのか?なぜ.NETのクラスが動的に呼び出せるのか?というところまでは追い切れていません。
    Windows PowerShell in Actionという書籍に詳しい解説があるそうなので、これから読んで、みなさんにお伝えできたらいいなと思っています(購入してるのですが積読状態です(汗)。

    あと中さんからエイリアスを使う上では注意が必要というコメントをいただきました。これまでのコマンドプロンプトと同名のエイリアスがあるが、それらを書くときは、オプションなどは従来とは異なるということを言っておかないと混乱する…ということですよね?>中さん
    エイリアスはシェルを叩く際はデフォルトで定義されている分には積極的に使っていってもいいと思いますが(コマンドプロンプトと混同しないように、との前提が必要ですが)、スクリプトで使うときはあえてエイリアスを使うこともないかなぁと思います。
    ?や%などはエイリアスというか文法チックなので、こちらのほうが分かりやすいような気もします。
    エイリアスとは少し離れますが、パイプを多用したスクリプトの分かりやすい記法というのも研究中です。PowerShellはやはりオブジェクトが渡るパイプが肝なので、スクリプトでも活用していきたいのですが、多用するとどうしても読みにくくなってしまいます。そのあたりをうまく解消できればいいですね。

    次回(1/12(金))はまたよろしくお願いします。まだまだ勉強中なのでなかなか講演、執筆ともに拙かったり進捗が遅かったりして申し訳ありません。取り上げてほしいこと、スクリプトのネタなどがありましたらぜひフィードバックをお寄せください。

    元記事:http://blogs.wankuma.com/mutaguchi/archive/2006/12/18/51695.aspx

    2006/11/07

    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


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

    Twitter

    Books