しばたテックブログ

気分で書いている技術ブログです。

PowerShell 6.0がリリースされました

PowerShell

既に日本語情報も出回っていますが、2018/1/10(PST)*1にPowerShell 6.0が正式リリースされました。

f:id:stknohg:20180115003255p:plain

公式情報は以下になります。

blogs.msdn.microsoft.com

2016年にPowerShellがオープンソースになりPowerShell 6.0のアルファ版がリリースされてから約1年半経ってのリリースとなりました。
ここ最近のPowerShellの変化についていろいろと思うところはあるのですが、それはひとまず置いておいてこのリリースを祝いたいと思います。

本エントリでは先のPowerShell Team Blogの内容をベースにPowerShell 6.0の新機能などについて触れていきます。

PowerShell 6.0のインストール

PowerShell 6.0は.NET Coreを基盤としたクロスプラットフォームなアプリケーションになりました。
WindowsだけでなくLinuxやMacにもインストール可能となり、

  • Windows 7, 8.1, and 10
  • Windows Server 2008 R2, 2012 R2, 2016
  • Windows Server Semi-Annual Channel
  • Ubuntu 14.04, 16.04, and 17.04
  • Debian 8.7+, and 9
  • CentOS 7
  • Red Hat Enterprise Linux 7
  • OpenSUSE 42.2
  • Fedora 25, 26
  • macOS 10.12+

といったプラットフォームをサポートしています。
また、まだ公式なサポートはしていませんが、

  • Arch Linux
  • Kali Linux
  • AppImage (works on multiple Linux platforms)
  • Windows on ARM32/ARM64
  • Raspbian (Stretch)

でも動作させることが可能です。

インストール方法についてはこちらから各プラットフォーム毎のインストーラーを入手することができます。

WindowsではMSIインストーラーからのインストール、LinuxではYumやApt、MacではHomebrew Caskといったパッケージ管理ツールからのインストールも可能です。

blog.shibata.tech

blog.shibata.tech

blog.shibata.tech

PowerShellのエディションと下位互換について

blog.shibata.tech

以前にも説明しましたが、PowerShellは従来のWindows PowerShellと.NET CoreをベースとしたPowerShell Coreに分類され、PowerShell 6.0はPowerShell Coreのみのリリースとなります。

Windows PowerShell

  • PowerShell 1.0～5.0、およびDesktop EdtionのPowerShell 5.1
  • Windowsの.NET Framework上で動作するバージョン
  • PowerShell 5.1では $PSVersionTable.PSEdition = 'Desktop'となる

PowerShell Core

  • Nano Server向けのPowerShell 5.1、およびPowerShell 6.0
  • (Windowsを含め)プラットフォームを問わず.NET Core上で動作するバージョン
  • $PSVersionTable.PSEdition = 'Core'となる

f:id:stknohg:20170719234440p:plain

バージョン番号は連続していますがアプリケーション基盤が異なるためPowerShell 6.0はこれまでのPowerShellとは実質別物です。

基盤となる.NET Core自体が.NET Frameworkのサブセットということもあり、できるだけ互換性を維持する様にされているものの、これまでのWindows PowerShellに対して多くの点で互換性の不足、破壊的変更がなされれています。

たとえばPowerShell 6.0では以下の機能が削除されました。

  • PowerShell Workflows
  • PowerShell Snap-ins
  • WMIv1 Cmdlets (Get-WmiObject, Invoke-WmiMethod, etc.) : 代わりにCIM Cmdlets(Get-CimInstance, Invoke-CimMethod, etc.)を使います
  • DSCリソースの実行基盤 : 代わりにDSC Coreがリリースされる予定です

そして、PowerShell 6.0における破壊的変更については以下にまとめられています。

* https://github.com/PowerShell/PowerShell/blob/master/docs/BREAKINGCHANGES.md

【2018/02/11追記】

破壊的変更についてまとめました。

blog.shibata.tech

【追記ここまで】

今後の方針としてPowerShell CoreでWindows PowerShellを置き換えていきたい展望はある様ですが、現時点ではとてもその水準には達していないのが率直なところです。

このためWindows環境においてはWindows PoweShell + PowerShell Coreと併用して運用し、少しずつPowerShell Coreへのシフトを図っていくのが良いでしょう。
(個人的にはクロスプラットフォーム化を意識する必要がないのであれば いまのところは 無理にPowerShell Coreに手を出さなくても良いと思っています。ただWindows PowerShellは今後大きな変更はなされないため先を見据えておくこと自体は必要でしょう。)

PowerShell 6.0の新機能について

PowerShell 6.0の新機能については以下にまとめられています。
(量が多いので近いうちに別エントリでまとめたいですね...まとめました。)

【2018/02/09追記】

新機能についてまとめました。

blog.shibata.tech

【追記ここまで】

本ブログでもその一部についてエントリを起こしているので参考にしてください。

PowerShell Coreのサポートサイクルについて

PowerShell CoreのサポートはMicrosoft Modern Lifecycle Policyに準じる様になり、基本的には、

  • 従来の有償サポートを受けるには最新版のプログラムを使用しておくこと
  • コミュニティサポートはGitHubで行う(なお、Windows PowerShellについては従来通りUserVoiceを使う)
  • PowerShell 6.xは約半年毎に更新され新しいバージョン(6.1、6.2...)をリリースする予定

といった方針になるそうです。

細かい話はPowerShell Core Support Lifecycleをご覧ください。

Windows PowerShellのサポートサイクルについて

【2018/01/16追記】

Windows PowerShellは今後大きな機能追加や優先度の低い不具合の修正は行われませんがサポート自体はOSのサポートと共に引き続きます。
(つまりOSのサポート終了までWindows PowerShellはサポートされます)

ただし、PowerShell 2.0の利用はすでに非推奨となっています ので最新のPowerShell 5.1に更新しておくのが良いでしょう。

blogs.msdn.microsoft.com

最後に

まだまだお伝えしなければならないことは多いのですが1エントリでまとめるには流石に厳しいので本エントリはこの辺にしておきます。

これからも新しく生まれ変わったPowerShellの情報をできる限りお伝えしていきたいと思います。

*1:日本時刻だと2018/1/11

Windows 7にPowerShell 6.0をインストールする - 再び

PowerShell Windows

blog.shibata.tech

の続きです。

前回はPowerShell 6.0アルファ版で試しましたが、今回はGAリリース直前のRC2で試しています。

基本的な手順は前回と変わらないのですが、前提条件が若干変わったため、その点を補足するかたちで本エントリを書きます。

前提条件

Windows 7にPowerShell 6.0をインストールするための前提条件は以下となります。

  1. SP1が適用されていること
  2. Universal C Runtimeがインストールされていること
  3. KB2533623が適用されていること
  4. WMF 4.0 ～ 5.1がインストールされていること

SP1の適用について

前回はSP1の適用について明記されていませんでしたが、現在は公式のインストール手順に

To install PowerShell on Windows Full SKU (works on Windows 7 SP1 and later), download either the MSI from AppVeyor for a nightly build, or a released package from our GitHub releases page. The MSI file looks like this - PowerShell-6.0.0..<os-arch>.msi

と Windows 7 SP1以降であることが明記されています。

この点に関しては、前回の時点でSP1未適用のWindows 7はすでにサポート切れであったため単純に記載していなかっただけの様です。

Universal C Runtimeのインストールについて

前回はVisual Studio 2015 の Visual C++ 再頒布可能パッケージのインストールが要求されていましたが、これがUniversal C Runtimeに変更されています。

現在はインストーラーでUniversal C Runtimeが必要かを判断し、必要とされる場合は下図の様に警告が表示されてインストールが中断されます。

f:id:stknohg:20171227174300p:plain

リンク先からZipファイルをダウンロードし、該当する.msuファイルを適用してください。

  • Windows 7 SP1(32Bit版) : Windows6.1-KB3118401-x86.msu
  • Windows 7 SP1(64Bit版) : Windows6.1-KB3118401-x64.msu

なお、Universal C RuntimeのインストールにはSP1が適用されている必要があります。

KB2533623の適用について

.NET Coreの利用に必要な事前条件としてKB2533623の適用が必要です。

こちらは前回から変わっていません。

WMF 4.0 ～ 5.1のインストールについて

前回とは異なりWMF 4.0 ～ 5.1の事前インストールが必要となりました。
こちらのPull Requestにその理由が記載されており、

github.com

On Win7, WMF 4.0 or higher version needs to be installed so that the WinRM can support the side-by-side remoting plugin. So I make the WMF 4.0 a prerequisite too.

とPowerShell Remotingを有効にするために必要になったそうです。

こちらもインストーラーでPowerShell Remoting Plugin(pwrshplugin.dll)のインストールを判断し、WMF 4.0以降がインストールされていないと判断された場合は警告が表示されてインストールが中断されます。

f:id:stknohg:20171227174340p:plain

特に制限が無いのであればWMF 5.1をインストールすれば良いでしょう。
手順は以下のエントリを参考にしてください。

blog.shibata.tech

ちなみに、あまりお勧めできない裏技として、PowerShell 6.0をZipファイルからインストールすればWMF 4.0 ～ 5.1がインストールされていない環境でも動作させることは可能です。
ただし、PowerShell Remotingは使えませんし、予期せぬエラーが起きても自己責任でお願いします。

f:id:stknohg:20171227174419p:plain

(右がZipファイルをダウンロードして動かしたpwsh.exeです。)

WMF 4.0以降をインストールできない事情のある環境で役に立つこともある...やもしれません。

インストール手順

事前条件をクリアしていれば、インストールはMSIインストーラーの指示に従うだけでOKです。

前項で触れた様にZipファイルからインストールしても構いません。

細かい説明はしませんがMSIインストーラーのスクリーンショットだけ貼っておきます。

f:id:stknohg:20171227174447p:plain

f:id:stknohg:20171227174504p:plain

f:id:stknohg:20171227174520p:plain

f:id:stknohg:20171227174532p:plain

f:id:stknohg:20171227174546p:plain

f:id:stknohg:20171227174559p:plain

これで無事PowerShell 6.0を起動することができます。

f:id:stknohg:20171227174622p:plain

PowerShell 6.0からジョブの実行に & が使える様になります

PowerShell

PowerShell 6.0 Beta.2からジョブの実行方法が拡張され、文の最後*1にアンパサンド(&)を付けることでジョブを起動することができる様になりました。

これはBash等のシェルにある機能と同等のものですが、PowerShellには従来からバックグラウンドで別プロセスのPowerShellを起動するジョブの仕組みがあり、&はその糖衣構文な感じで実装されました。

& によるジョブの起動例

簡単な例として

dir &

と実行するとジョブが起動され以下の様な画面になります。

f:id:stknohg:20171224104740p:plain

この記述は概ね

Start-Job -ScriptBlock {dir}

と一致し、その結果については従来どおりReceive-Jobなどで取り扱うことが可能です。

f:id:stknohg:20171224104758p:plain

& によるジョブ起動の詳細

さきほど 概ね一致 と書きましたが実際には幾つかの点が異なります。

ジョブ起動時のロケーション

&でジョブを起動したときは自動で以下のコマンドが挿入され現在のロケーションをジョブに引き渡す様になっています。

Microsoft.PowerShell.Management\Set-Location -LiteralPath $using:pwd ;

Start-Jobでジョブを起動した場合は何も挿入されません。

f:id:stknohg:20171224104823p:plain

変数の自動引き渡し

&でジョブを起動したときは自動で変数にusingスコープが付与され、その値がジョブに引き渡されます。

例として

$message1 = "Hello"
Write-Output $message1 &

を実行するとジョブで実行されるコマンドは

Microsoft.PowerShell.Management\Set-Location -LiteralPath $using:pwd ; Write-Output ${using:message1}

となり、message1変数にusingスコープが付与されていることが確認できます。
ジョブの結果を見てもちゃんとmessage1変数に値が渡されています。

f:id:stknohg:20171224104858p:plain

Start-Jobでジョブを起動する場合、usingスコープは自分で付与しなければなりません。
以下の様にジョブを実行してしまうとmessage2には何も設定されませんので注意が必要です。

$message2 = "World"
Start-Job -ScriptBlock { Write-Output $message2 }

f:id:stknohg:20171224105058p:plain

最後に

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

これまでちょっと実行するのが面倒であったジョブの仕組みですが、&の登場によりより手軽にできる様になったと思います。

補足

本エントリはPowerShell Advent Calendar 2017 22日目の代理投稿になります。

*1:文法上正確にはパイプラインの最後になりますが、ここではわかりやすさのために文の最後と表記します