PowerShell 6.0のBeta版がリリースされました

公式の案内はこちら。

blogs.msdn.microsoft.com

GitHubのマイルストーンにあった通りBuild 2017に合わせる形のリリースとなりました。

インストールおよびアップデート

GitHubから最新のインストーラーをダウンロードして上書きインストールするか、Linux環境であればyumやapt-getを使って最新バージョンにしてください。

stknohg.hatenablog.jp

主な変更点

詳細については先のブログかGitHubのチェンジログを参照してください。

本エントリでは主要な部分だけ解説します。

インストール可能なLinuxディストリビューションが増えました

オープンソース化したAlpha 9時点でインストール可能なディストリビューションは

• Ubuntu 14.04, 16.04
• CentOS 7

でしたが、現在は、

• Ubuntu 14.04, 16.04
• CentOS 7
• Debian 8
• RHEL 7
• OpenSUSE 42.1
• Arch Linux

にインストール可能となっています。
またAppImageのバイナリも提供されているので、AppImageが利用可能な環境であればディストリビューションを選ばずにPowerShellを実行することができます。

.NET Standard 2.0への移行

Alpha18までは.NET Core 1.0→1.1上で動作していましたが、Beta1になった時点で.NET Core App 2.0.0(Preview1)上で動作する様になりました。

こちらについては、私自身が.NET Standard 2.0のうま味をよくわかっていないため何とも言えないのですが、PowerShell Moduleのポータビリティが上がるだろうとの事です。

テレメトリの追加

Beta1になってPowerShell CoreにApplication Insightsを利用したテレメトリ(利用環境などの情報収集機能)が追加されました。

現時点では利用者のOS($PSVersionTable.OS相当)とPowerShellのバージョン($PSVersionTable.GitCommitId)を収集しているそうです。

今後ほかの情報も収集して開発に利用する予定となっています。
収集する情報を増やす際は突然増やすことはせずにRFCによる議論を経てから行うとの事です。

そして収集した情報はこちらのダッシュボードで参照することができる様になるそうです。

ちなみに、この情報収集をオプトアウトするには$PSHOMEにあるDELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRYファイルを削除してください。

例としてPowerShell on Linux上で実行するならこんな感じになります。

# PowerShell on Linux
sudo rm $PSHOME/DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY

その他変更点

これらの他にチェンジログから個人的に気になる変更点をリストアップしておきます。*1
すべての変更点ではありませんので注意してください。

• Enable 'ConvertTo-Html' in PowerShell Core. (alpha11)
• Select-Object with -ExcludeProperty now implies -Property * if -Property is not specified. (alpha12)
• Enable Implicit remoting commands in PowerShell Core (alpha12)
• Add parameters -Top and -Bottom to Sort-Object for Top/Bottom N sort (alpha13)
• Add Get-Uptime to Microsoft.PowerShell.Utility (alpha13)
• Make Out-Null as fast as > $null (alpha13)
• New-TemporaryFile and New-Guid rewritten in C# (alpha14)
• Add -Group parameter to Get-Verb (alpha15)
• Use MB instead of KB for memory columns of Get-Process (alpha15)
• Add alias Path to the -FilePath parameter of Out-File (alpha16)
• Convert Get-FileHash from script to C# implementation (alpha16)
• Port *-CmsMessage and Get-PfxCertificate cmdlets to Powershell Core. (#3224) (alpha17)
• Add the -TimeOut parameter to Test-Connection. (#2492) (alpha17)
• Remove the AliasProperty "Count" defined for System.Array (alpha17)
• Add -CustomMethod parameter to web cmdlets to allow for non-standard method verbs. (#3142)
• Allow Windows' reserved device names (e.g. CON, PRN, AUX, etc.) to be used on non-Windows platforms. (#3252) (alpha17)
• Remove year from PowerShell copyright banner at start-up. (#3204) (alpha17)
• Add -Extension and -LeafBase switches to Split-Path so that you can split paths between the filename extension and the rest of the filename. (#2721) (alpha18)
• Implement Format-Hex in C# along with some behavioral changes to multiple parameters and the pipeline. (#3320) (alpha18)
• Add the OS entry to $PSVersionTable. (#3654) (beta1)
• Update PowerShell Core to accept the -i switch to indicate an interactive shell. (#3558) (beta1)
• Change the default encoding and OEM encoding used in PowerShell Core to be compatible with Windows PowerShell. (#3467) (beta1)
• Change the behavior of Remove-Item on a symbolic link to only removing the link itself. (#3637) (beta1)

今後のスケジュールについて

これまで一切明らかにされていなかった今後のスケジュールやマイルストーンについて以下の声明が出されました。

リリースサイクル

Beta版では約3週間のサイクルで新しいバージョンをリリースするとの事です。

明言はされてませんでしたがAlpha版でも同じくらいのサイクルで新バージョンがリリースされてましたので、今後も変わらずこれまで通りという事でしょう。

リリース候補に向けて

具体的な期限は切られませんでしたが、リリース候補を出すために以下の項目をクリアするとの事です。

1. 6.0.0-betaのマイルストーンに紐づけられたIssueを解決する

2. 最低80%のコードカバレッジを達成する
   (現時点では約40%達成)

3. バージョン6.0.0に向けたすべてのシナリオを実現する

4. テレメトリに基づいた利用目標を達成する
   (いまいちよくわかりませんが詳細はこれから決める様です...)

これらの項目をクリアしたら即リリースというわけではありませんがリリース時期を予測するのによい指標になると思います。

最後に

とりあえずこんな感じです。

GitHubの更新などをずっと追いかけてきた印象ですが、バージョン6に向けてPowerShellは着実に進化していると感じます。

これからの更新がとても楽しみですね。

*1:邦訳したかったけど量が意外と多かったので原文のままで...

Windows 10でロードアベレージを取得する？

小ネタです。

ふと、「Bash on Ubuntu on Windowsを使えばWindowsでもロードアベレージを取得できるよなぁ…」と思ったので実際に試してみました。

Windowsのロードアベレージ

www.atmarkit.co.jp

上の記事に詳細が説明されていますが、WindowsではUNIXやLinuxのロードアベレージと同等の値を取得することはできません。
類似の値としてパフォーマンスカウンターの\System\Processor Queue Lengthが紹介されており、通常はこれを使うしかありません。

PowerShellでこの値を取得するにはGet-Counterコマンドを使い以下の様にすれば良いです。

(Get-Counter -Counter "\System\Processor Queue Length").CounterSamples.CookedValue

このカウンターはデフォルトのスケールが1なのでCookedValueがそのまま使えます。

また、平均を取るには以下の様な感じすれば一応可能です。*1
(以下のサンプルを実行すると1分間待たされるので注意してください)

# UNIX/Linuxでのサンプリング間隔は5秒だそうなので、それに合わせて1分間の平均を求めます
(Get-Counter -Counter "\System\Processor Queue Length" -SampleInterval 5 -MaxSamples 12).CounterSamples.CookedValue `
    | Measure-Object -Average | Select-Object -ExpandProperty Average

Windows 10でロードアベレージを取得する

Windows 10でWSLを有効にすればWindows内でUbuntuが動作しますので、Ubuntu経由でロードアベレージの値が取得できるはずです。

Ubuntuでロードアベレージを取得するにはtop、uptimeといったコマンドや/proc/loadavgを参照すれば可能です。

やり方はいろいろありますが、今回は/proc/loadavgを参照する方法で2パターン試してみました。

方法.1

最初の方法はこんな感じです。

# PowerShell
'cat /proc/loadavg|awk ''{print "@{Load1="$1";Load5="$2";Load15="$3";}"}'';exit;' | bash | iex

実行結果)

UbuntuのBashで/proc/loadavgの値を取得、awkでPowerShellのHashTableの書式(@{Load1=$1;Load5=$2;Load15=$3;})に成形し、Invoke-Expression(iex)でHashTableに変換しています。

方法.2

もう一つの方法はこんな感じです。

# PowerShell
'cat /proc/loadavg;exit;' | bash | % {$v=-split $_;@{Load1=$v[0];Load5=$v[1];Load15=$v[2];}}

実行結果)

こちらは、Bashでは/proc/loadavgの値を取得するだけにして、PowerShellで値の成形をする様にしています。

他にもいろいろなやり方があると思います。
BashとPowerShellをどういった塩梅で組み合わせるかを考えるのはとても楽しいです。

残念なお知らせ

ここまで書いておいてアレなのですが非常に残念なお知らせがあります。

このエントリの内容を試している最中にロードアベレージの値が全然変化せず、違和感を感じたので調査してみたところ、以下のIssueが上がっていました。

github.com

現時点ではBash on Ubuntu on Windowsのロードアベレージは0.52 0.58 0.59のダミー値を返すというふざけた状態でした…*2
まだベータ版ですので値が取れないのは仕方ないと思いますが、せめて0 0 0といった自明な値にしておいてほしいものです。

こちらについては気長に待つしかないといったところでしょう。

最後に

最後にとんでもないオチがついてしまいましたがこんな感じです。
本エントリは現時点では全く役に立ちませんが、いずれ役に立つ日がくると信じています。

いまのところはBashとPowerShellを組み合わせて使う一例として見ていただければと思います。

*1:実運用では使えないと思いますが…

*2:しばらく普通に騙されてましたよ…

Pester 4での新機能・変更点まとめ

元ネタはこちら。

github.com

そろそろPester 4のリリースも近づいているかなと思い、新機能や変更点をざっくりとまとめてみました。

Pester 4のインストール

現時点での最新版はVer.4.0.3(Release Candidate扱い)となっており、PowerShell Galleryから入手することができます。

Install-Module Pesterコマンドで普通にインストールできるはずですが、PowerShell 5.0以降の環境であれば標準でPester(Ver.3系)がインストール済みであるため-Forceや-SkipPublisherCheckgetパラメーターを指定する必要があるかもしれません。
私の環境では両方のパラメーター指定が必要でした。

インストール例)

Install-Module Pester -Scope CurrentUser -Force -SkipPublisherCheckget

これでPester 4の新機能を試すことができます。

1. 文法の変更

最初はVer.4で発生した文法の変更について記載します。

Shouldとともに使用していたBe等の動詞がVer.4から名前付きのダイナミックパラメーターとなり、-Beの様に指定することが可能になりました。
互換性を維持するため従来の記法は残されていますがいずれ廃止されるそうです。(時期は未定)

以下に簡単な例を示します。

# 従来の文法
Import-Module Pester -MaximumVersion 3.4.0 -Force

Describe '従来の文法 - 動詞のパラメーター化' {
    It '足し算のテスト' {
        1 + 1 | Should Be 2
    }
}

# Ver.4からの文法
Import-Module Pester -MinimumVersion 4.0.3 -Force

Describe '新しい文法 - 動詞のパラメーター化' {
    It '足し算のテスト' {
        # BeなどがShouldの名前付きパラメーターに
        1 + 1 | Should -Be 2
    }
}

この変更によりISEやVSCodeなどのインテリセンスに各動詞が表示される様になり、よりコーディングがしやくすなります。

2. 配列を入力する際の仕様変更

Should Beにおける配列の扱いがVer.4から変更されます。

Ver.3までは以下のテストは$trueを返していましたが、Ver.4からこれは$falseを返す様になります。

# 従来の挙動
Import-Module Pester -MaximumVersion 3.4.0 -Force

Describe '従来の文法 - 配列の挙動' {
    It 'バージョン3までは通るテスト' {
        @( $true, $true, $true ) | Should Be $true
    }
}

Ver.4からこのテストを通すには以下の様に記述する必要があります。

# Ver.4からの挙動
Import-Module Pester -MinimumVersion 4.0.3 -Force

Describe '新しい文法 - 配列の挙動' {
    It 'バージョン4で通るテスト' {
        @( $true, $true, $true ) | Should -Be @( $true, $true, $true )
    }
}

見てわかるかと思いますが、Ver.4からはShouldに対して配列の要素ではなく配列全体が比較の対象になる様に変更されています。

3. 表示色の刷新

Ver.4からテスト結果の表示色が新しくなります。

Ver.3までの色はこちら。

Ver.4からの色はこちら。

色を変えた意図がいまいち掴めなかったのですが、コミットログを追う限りでは、従来ホスト毎にカラースキームを持ち色分けしていた部分を統一しシンプルにした影響を受けている様です。

4. ContextとDescribeのネスト

Ver.4からContextとDescribeをネストすることが可能になります。
Ver.3まではネストするとエラーになりました。

設定例)

# Ver.4からの挙動
Import-Module Pester -MinimumVersion 4.0.3 -Force

Describe '新しい文法 - Describe ネスト1' {
    Describe '新しい文法 - Describe ネスト2' {
        Context '新しい文法 - Context ネスト1' {
            It '足し算のテスト' {
                1 + 1 | Should -Be 2
            }
        }
    }
}

5. Gherkinのサポート

Ver.4からPesterでGherkin(ガーキン)を使ったFeatureファイルによるテストがサポートされる様になりました。

Gherkinとは何ぞやといった話については、

いまさら聞けないTDD/BDD超入門（2）：TDD／BDDの思想とテスティングフレームワークの関係を整理しよう (3/3) - ＠IT

や

Cucumber のフィーチャの文法 - Gherkin | そんなこと覚えてない

が参考になります。

使い方としては、Featureファイル(ほげほげ.feature)とStepファイル(ほげほげ.steps.ps1)を記述し、Invoke-Gherkinコマンドを呼ぶことでテストを実行することができます。
Featureファイルにおける各機能は以下の様にPesterの機能と対応しています。

• Feature(フィーチャ) = Describe
• Scenario(シナリオ) = Context
• 各ステップ = It

正直良い例が思いつかなったので、先述の@ITの記事にあるサンプルをPesterに合わせた形にして例示します。

Featureファイル(Sample.feature)

# language: ja
フィーチャ: TDDのサイクルはRED、GREEN、REFACTORからなっています。
  GREENからREFACTORを飛ばすことはありますが、REDからGREENを飛ばしてREFACTORしないのが特徴です。
  これはテストなどによって保証されている範囲でのみ内部を変更することを「REFACTORING」と呼ぶという定義によるものです。
  
  シナリオ: プロジェクトを始めるときにTDDの最初の一歩になる手順
    前提 プロジェクトを始めるときはテストがない
    もし 要求を満たすテストを追加する
    かつ テストを実行する
    ならば テストが失敗して、TDDでいう「RED」になる

Stepファイル(Sample.steps.ps1)

Given 'プロジェクトを始めるときはテストがない' {
    # 処理
}
When '要求を満たすテストを追加する' {
    # 処理
}

And 'テストを実行する' {
    # 処理
}

Then 'テストが失敗して、TDDでいう「RED」になる' {
    # 処理
}

テスト実行例)

# カレントディレクトリにあるすべての.featureファイルを実行する
Invoke-Gherkin

# Pathを指定する場合
# [Feature名].Steps.ps1 という名称のStepファイルを自動で取り込む
Invoke-Gherkin -Path .\Sample.feature

実行した結果はこんな感じになります。
まだ英語以外の言語では警告がでる様です。

ちなみにGitHubにもサンプルがありますのでこちらを参照するのも良いかと思います。

6. 非推奨、または廃止された機能

Ver.4になって非推奨、または廃止された機能は以下となります。

• Invoke-Pesterの-Quietパラメーターは非推奨になり、代わりに-Show Noneを使うことが推奨されます。
  -ShowパラメーターにはPester.OutputTypes列挙型の値を指定することができ、以下の様に定義されています。

namespace Pester
{
    [Flags]
    public enum OutputTypes
    {
        None = 0,
        Default = 1,
        Passed = 2,
        Failed = 4,
        Pending = 8,
        Skipped = 16,
        Inconclusive = 32,
        Describe = 64,
        Context = 128,
        Summary = 256,
        Header = 512,
        All = Default | Passed | Failed | Pending | Skipped | Inconclusive | Describe | Context | Summary | Header,
        Fails = Default | Failed | Pending | Skipped | Inconclusive | Describe | Context | Summary | Header
    }
}

• New-TestDriveItemは無くなりました。(ただ、昔から無い様に見受けられます...)

• Invoke-Pesterの-OutputXmlパラメーターは無くなり、-OutputFileと-OutputFormatの組み合わせに変更されます。
  -OutputFormatはいまのところNUnitXmlのみですが、今後のバージョンで増える可能性はありそうです。

最後に

とりあえずこんな感じです。
Pester 4のリリース時期はまだ具体的に決まっていない様ですが、今から備えておくのも良いかと思います。