しばたテックブログ

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

Windows Subsystem for Linux(Ubuntu)にRe:VIEWをインストールする

github.com

流行りのRe:VIEWを試してみたくなったので手元のWindows 10にインストールしてみました。

Re:VIEW on Windows

Windows上でRe:VIEWを試すには色々な方法があり、公式にはDocker Toolboxを使う方法が紹介されています。
今回私はWindows Subsystem for Linux(WSL)のUbuntu上にRe:VIEWをインストールする方法を採りました。

環境は以下となります。

  • 最新のWindows Updateを適用した64bit版 Windows 10 Pro (1709)
  • WSL上のUbuntu 16.04

Re:VIEWのインストール

本エントリではWSL上のUbuntuを用意する手順は端折ります。
MicrosoftストアからUbuntuをインストールして初期ユーザー設定を済ませた状態をスタート地点とします。

rbenvとRubyのインストール

Re:VIEWはRuby製アプリなので最初にRubyの実行環境を用意します。
以下のドキュメントを参考にしてrbenvとRubyをインストールします。

WSLのUbuntu(bash.exe)を起動し以下のコマンドを順に実行します。
今回はRuby 2.5.0をインストールしました。

# 前準備の apt-get update
sudo apt-get update -y
# rbenvのコンパイルに必要
sudo apt-get install -y gcc make
# Rubyのビルドに必要。バージョンによって変わるやも?
sudo apt-get install -y libssl-dev libreadline-dev zlib1g-dev

# rbenvのインストール
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
chmod go-w -R ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
source ~/.bash_profile

# ruby-buildのインストール (rbenv installコマンドに必要)
mkdir -p "$(rbenv root)"/plugins
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

# Rubyのインストール
#   今回は Ruby 2.5.0をインストール
rbenv install 2.5.0

# システム全体でのデフォルトバージョンを指定
rbenv global 2.5.0

Re:VIEWインストールの前準備

WSL側から見たWindows(/mnt/c/配下のディレクトリ)の任意の場所にRe:VIEW用のディレクトリを作ります。
今回は/mnt/c/Temp/review(C:\Temp\review)を対象します。

# Windows側のディレクトリにファイルを作る
mkdir /mnt/c/Temp/review

Re:VIEWのインストール

前項で作成したディレクトリに移動してrbenvの設定とRe:VIEWのインストールを行います。
インストール自体はgem installでサクッと行けます。

# 移動
cd /mnt/c/Temp/review/

# このディレクトリで利用するRubyのバージョンを設定
rbenv local 2.5.0
# Re:VIEWのインストール
rbenv exec gem install review

(オプション)TeX Liveのインストール

Re:VIEWでPDFのドキュメントを生成する場合システムにTeXがインストールされている必要があります。
(PDFを出力しない場合は不要です)

本エントリでは以下のサイトの手順を参考にTeX Liveをインストールします。

TeX Liveのインストールはapt-get installでも可能ですが、最新のバージョンを使おうと思いネットワークインストーラを使用したインストールにしました。

# TeX Liveのインストール
cd ~
# 今回はJAISTを選んでいますが、ダウンロード先のアドレスはミラーサイトから適当に選んでください
curl -O http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/install-tl-unx.tar.gz
tar xvf install-tl-unx.tar.gz
cd install-tl*
sudo ./install-tl --repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/

# あとはインストーラーの指示に従う。
# 今回はデフォルト設定のままインストール続行。

# インストール後パス追加
sudo /usr/local/texlive/????/bin/*/tlmgr path add

また、現時点のRe:VIEW 2.5.0でソースコードのリストを使う場合、PDF生成時にjlisting.styが不足している旨のエラーが出ます。
こちらは以下のIssueでも認識されておりRe:VIEW 3.0で対処する見込みの様です。

とりあえず現状は公開されているサイトからjlisting.styをダウンロードして追加する必要があるので、以下のコマンドで追加しておきます。

# ソースコードのリストを使う場合はjlisting.styを追加
curl -OL https://ja.osdn.net/projects/mytexpert/downloads/26068/jlisting.sty.bz2
bzip2 -d ./jlisting.sty.bz2
sudo mv ./jlisting.sty /usr/local/texlive/2017/texmf-dist/tex/latex/listings
sudo chmod 644 /usr/local/texlive/2017/texmf-dist/tex/latex/listings/jlisting.sty
sudo mktexlsr

これで一通りのインストールは完了です。

Re:VIEWを試す

最後にインストールしたRe:VIEWを試してみます。

雛形作成

review-initコマンドでドキュメントの雛形を作成できますので適当な名前で作成します。
(今回はsample-docにしました)

cd /mnt/c/Temp/review/

# サンプル作成
review-init sample-doc

Windows側のディレクトリにサンプルを作っているのでVisual Studio Codeから内容を確認することができます。
Re:VIEW拡張をインストールしてればプレビュー表示も可能です。

f:id:stknohg:20180309174342p:plain

(上図ではクイックスタートガイドにあるテキストを試しています)

ドキュメント生成

前項で作成した雛形のルートフォルダでreview-epubmakerreview-pdfmakerコマンドを実行すればEPUBおよびPDFドキュメントを生成できます。
雛形にはRakeの設定も含まれているのでrakeコマンドから生成することも可能です。

cd /mnt/c/Temp/review/sample-doc/

# EPUB生成
review-epubmaker config.yml
# rake epub でも良い

# PDF生成
review-pdfmaker config.yml
# rake pdf でも良い

生成されたEPUBとPDFは以下の様な感じになりました。

f:id:stknohg:20180309174416p:plain

f:id:stknohg:20180309174425p:plain

とても良い感じですね。

PowerShellの三項演算子について

あまりにも今更なはなしなのですが、根強い需要があるみたいなのでざっくりブログに書いておきます。

【2019/09/20追記】PowerShell 7の三項演算子

本日PowerShell 7 Preview.4がリリースされ、このバージョンの新機能の一つとして三項演算子が導入されました。
詳細を別エントリーにまとめていますのでこちらも併せてご覧ください。

dev.classmethod.jp

PowerShellの三項演算子

はじめに結論を書いておくと、現在、PowerShellに三項演算子はありません。
PowerShell 1.0 ~ PowerShell Core 6.0に至るまでどのバージョンでもサポートされていません。

ただ、三項演算子に対する要望はPowerShellがリリースされた当初からあった様で、オープンソース化した現在も以下のIssueで要望と提案がなされています。

github.com

私自身は三項演算子に対する思い入れは全くないので気にしていませんが、気になる方はこちらのIssueに積極的に参加していくと良いでしょう。

三項演算子の代わりになるもの

で、これで終わってしまうとあまりにも芸がないので三項演算子の代わりになる方法をいくつか紹介します。

1. if文

一般的なプログラミング言語に慣れている方には受け入れ難い動作かもしれませんが、PowerShell 2.0からif文が値を返す動作をします。

このため、

$result = if($condition){ Write-Output "True" }else{ Write-Output "False" }

の様な記述を三項演算子の代わりに使うことができます。
なお、式の中でこれを使いたい場合は、

"Result is " + $(if($condition){ Write-Output "True" }else{ Write-Output "False" })

の様に部分式($())にしてやればOKです。

イメージとしてはVB.NETのif演算子が近いでしょうか。


余談ですが、PowerShellにおける文と式の曖昧さ、そしてパイプライン文については牟田口先生のこちらの考察をご覧ください。必見です。

winscript.jp

2. 2値配列

ショートコーディングのテクニックの一つなのですが配列で三項演算子を代用することができます。

スクリプト中で使うことはあまりお勧めしませんがちょっとしたワンライナーを書くときのテクニックとして覚えておいて損はないかと思います。

以下の様に2値の配列にTrue、Falseごとの処理を記述し、配列の要素指定に条件を記述します。

$result = &({ Write-Output "True" }, { Write-Output "False" })[!$condition]

[int]$false = 0[int]$true = 1と暗黙的に型変換されることを利用してそれぞれの条件を実行するテクニックです。

3. Invoke-Ternary

最初に触れたPowerShell Team Blogの記事からの引用です。

# 定義
filter Invoke-Ternary ([scriptblock]$decider, [scriptblock]$ifTrue, [scriptblock]$ifFalse) 
{
    if (& $decider) { 
        & $ifTrue
    } else { 
        & $ifFalse 
    }
}
Set-Alias ?: Invoke-Ternary -Option AllScope -Description "PSCX filter alias"

# 使用例
1..10 | ?: {$_ -gt 5} {"Greater than 5";$_} {"Not greater than 5";$_}

関数やフィルターを作ってしまうならコレにこだわらず自分の好きな様に作ってしまうのが良いでしょう。

最後に

ほかにも色々なやり方で三項演算子を代用することができると思いますが本エントリではこのくらいにしておきます。

PowerShell Core 6.0 破壊的変更まとめ

公式情報はこちら。

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

公式情報では結構説明が端折られており、元になったIssueやPull Requestを読み込まないとわかりにくい部分があったため、本エントリではそのあたりを補足しつつ説明していきます。
一部の内容は新機能まとめと被っているのですがそのまま説明します。

PowerShell Coreでサポートされなくなった機能

PowerShell Workflow

PowerShell 3.0より導入されたワークフローの機能ですが、内部基盤であるWorkflow Foundationが.NET Coreに移植されておらずその予定も無いこともありPowerShell Coreには導入されません。
PowerShell Teamとしても導入の予定はないと明言しています。

正直なところ「これ使ってるひといる?」といった現状なので廃止もやむを得ないと思います。

カスタムスナップイン

スナップインの機能はPowerShell 1.0からの機能ですが、PowerShell 2.0から導入されたモジュールによってその役割は置き換えられ現在では非推奨の機能となっています。
この前提もありPowerShell Core 6.0では完全にサポートされなくなりました。

現在ところ、この変更によりPowerShell CoreではActiveDirectoryDnsClientモジュールが利用できなくなる影響が出ています。

WMI v1 Cmdlets

Get-WmiObjectなどの古いWMI関連のコマンドレットは廃止されました。
これは最初のPowerShell CoreであるNano Server向けのPowerShell 5.1がリリースされた時*1からの変更になります。

代わりにGet-CimInstanceなどのCIM Cmdletsを使用して下さい。

Microsoft.PowerShell.LocalAccounts

新機能まとめでも触れましたが、Microsoft.PowerShell.LocalAccountsモジュールはサポートされていないAPIを使用しているため削除されています。

GitHubの内容を見る限りでは、良い実装方法が見つかれば機能を復活させる様です。

*-Counter Cmdlets

パフォーマンスカウンター系の機能もMicrosoft.PowerShell.LocalAccountsと同様の理由で削除されています。

エンジン/言語に関する変更

powershell(.exe)からpwsh(.exe)への改名 (#5101)

本ブログでも何度か触れている通りです。

blog.shibata.tech

(Tableフォーマットを除いて)出力に改行を入れなくなりました (#5193)

タイトルがわかりにくいのですが、これまでのPowerShellにおいてコンソールへの文字列出力はコンソール幅の影響を受け、コンソール幅を超えるときは出力が打ち切られることがありました。

これを回避するためにOut-String -Widthを使って出力幅を指定する必要がありました。

# 例) 出力結果がコンソール幅で打ち切られない様にOut-String -Widthを使う
Get-StartApps | Out-String -Width 1024

PowerShell Core 6.0ではこの点が改善され、コンソールへの出力内容はコンソール幅の影響を受けなくなりました。

「Tableフォーマットを除いて」とあるのはTableフォーマットの場合は列幅が決められている場合があるので、その場合は出力の省略がこれまで通り行われます。

値型のコレクションに対するNULL要素のチェックが廃止されました (#5432)

Mandatory属性やその内部で使用されるValidateNotNullValidateNotNullOrEmpty属性において、検証処理の性能改善のために要素が値型であるコレクションが渡された場合は(値型であればNULLにならないため)そのNULLチェックをしない様に内部処理が変更されています。

この変更による影響ですが、要素の検証がスキップされる(=要素へのアクセスが無い)のでコレクションのGetEnumerator()の挙動に差異が発生します。
元のPull Request(#5432)にある例を出しておきます。

function bar {
   param ([ValidateNotNull()] $object)
   "MoveNext:  $($object.MoveNext())"
}

bar -object @(1,2,3).GetEnumerator()

Windows PowerShellではこの結果が$false(検証時に全要素にアクセスしているため)となり、PowerShell Coreでは$true(要素へのアクセスが発生しないため)となります。

# PowerShell 5.1まで
PS C:\> bar -object @(1,2,3).GetEnumerator()
MoveNext:  False

# PowerShell Core 6.0
PS C:\> bar -object @(1,2,3).GetEnumerator()
MoveNext:  True

$OutputEncodingの既定値をASCIIからBOMなしUTF-8に変更しました (#5369)

blog.shibata.tech

で触れたとおりです。

非WindowsなOSはだいたいUTF-8で動くのと、WindowsにおいてもASCIIは厳しいといった現状から変更に至っています。
事の経緯についてはこちらのIssue(#4681)をご覧ください。

ほぼ全ての既定のエイリアスからAllScopeオプションを取り除きました (#5268)

エイリアスのAllScopeオプションは、ヘルプから引用すると、

エイリアスは、新たに作成されるすべてのスコープにコピーされます。

といった役割を持つものですが、通常のPowerShellの利用においては基本気にしなくても問題ないでしょう。

この変更はパフォーマンスの改善を目的として実施されています。
これにより15~20%程度スコープ作成処理の高速化が見込みまれているそうです。

GitHubのコミットログを見ると

  • foreach
  • %
  • where
  • ?
  • select
  • cp
  • cd
  • dir
  • echo

以外のエイリアスが対象となっています。
上記エイリアスを変更しなかったのは、よく使われるであろうエイリアスに対してはAllScopeオプションを指定していた方がエイリアスのルックアップが早くなるためだそうです。

-Verbose-Debugパラメーターは$ErrorActionPreferenceの設定を上書きしなくなります (#5113)

PowerShellの微妙な仕様として、コマンドレットの実行時に-Verboseを指定すると$ErrorActionPreferenceの値をContinueに強制してしまう挙動があります。
(-Debugを指定した場合はInquireが強制されます)

例)

PowerShell Core 6.0ではこの挙動が改善され、-Verbose-Debugパラメーターを指定した場合に$ErrorActionPreferenceの設定を上書きしない様になりました。


余談なのですが、この挙動は$WarningPreferenceについても同様なのですが修正の対象とはなっていないので$WarningPreferenceは従来通りの挙動となります。

もし$WarningPreferenceについても気になる方がいらっしゃればIssueを上げるとよいでしょう。
(個人的には$WarningPreferenceはたいして使わないでしょうし問題ないと判断しています。)

コマンドレットの変更

Invoke-RestMethodはデータが何もなかった場合は情報を返さななくなりました (#5320)

Invoke-RestMethodはWEB APIがnullを返す際に文字列の"null"と解釈することがあり、今回の変更で$nullとして扱い情報を返さない様になったとのことです。

ただ、もとのIssueを読みながら色々試してみたのですが、良い感じの例を出すことができませんでした...

*-Computerなコマンドレットから-ComputerNameパラメーターを削除しました (#5227)

  • Rename-Computer
  • Restart-Computer
  • Stop-Computer

が対象です。
対象マシンを指定する-ComputerNameパラメーターはDCOM依存であり、.NET CoreでDCOMがサポートされていないための削除となります。
代わりにInvoke-Commandを使ってリモートコマンドを実行してください。


と、書かれてるのですが...ソースを読む限りではあくまでもDCOM(=>WMIv1)に依存するコードのみ削除されており-ComputerNameは普通に残っており使えます。
-ComputerNameパラメーターを使った場合はWSMan(=>CIM)を使ってリモートコンピューターに対してコマンドを実行し、代わりに-Protocolパラメーターが削除されています。

単純に記述が間違っている様です。

*-Serviceなコマンドレットから-ComputerNameパラメーターを削除しました (#5090)

基本的には前項と同様です。
PowerShell Coreのコマンドレット全般で-ComputerNameパラメーターは削除されています。

-LiteralPathパラメーターがワイルドカード文字を展開しなくなりました (#5197)

例として

Get-Item -LiteralPath a*b

が挙げられており、Windows PowerShellではこの場合-Path a*bと同様に扱われワイルドカード検索していましたが、PowerShell Coreではワイルドカードの展開は抑制されます。

Import-CsvPSTypeNamesの指定を受け入れる様になりました。 (#5134)

Windows PowerShellではExport-CSVで出力したCSVについているPSTypeNames(先頭の#TYPE [型名]の部分)がImport-Csvで正しく反映されなかったのですが、これがPowerShell Core 6.0で改善されています。

もとのIssue(#5134)からサンプルを例示しておきます。

  • エクスポート
[PSCustomObject]@{
    PSTypeName = 'My.Custom.Object'
    Column1 = 'values1'
} | Export-Csv .\csv.csv
  • 出力されるCSV
#TYPE My.Custom.Object
"Column1"
"values1"
  • インポート
$import = Import-Csv .\csv.csv
$import.PSObject.TypeNames
  • 結果
# PowerShell 5.1まで
CSV:My.Custom.Object

# PowerShell Core 6.0
My.Custom.Object
CSV:My.Custom.Object

Export-Csv-NoTypeInformationパラメーターが既定となりました (#5131)

-NoTypeInformationは前項で説明したPSTypeNamesを出力しないオプションになります。

単純にCSVファイルを出したい場合PSTypeNamesは不要な情報であり、実際不満の声が大きかった様でデフォルトでPSTypeNamesを出力しない様に改善されました。

PowerShell Coreではこれまでとは逆に-IncludeTypeInformationパラメーターをつけることでPSTypeNamesを出力する様になります。

Web Cmdletsでは暗号化されていない通信で-Credentialを使うと警告を出す様になりました (#5112)

暗号化されていない通信はHTTP接続のことです。

「警告」と言っていますが、実際には-AllowUnencryptedAuthenticationパラメーターをつけない限りはエラーとなります。

# PowerShell Core 6.0
$cred = Get-Credential

# 警告メッセージを出してエラー
Invoke-WebRequest http://contoso.com/ -Credential $cred

# 実行可能
Invoke-WebRequest http://contoso.com/ -Credential $cred -AllowUnencryptedAuthentication

APIの変更

AddTypeCommandBaseクラスは削除されました (#5407)

Add-Typeコマンドレットの性能改善の一環としての変更です。
Add-Type以外に影響はないとのことです。

ちなみに、新機能まとめでも触れていますが、Add-Typeはこれから破壊的変更が入る見込みです。

-EncodingパラメーターがSystem.Text.Encoding型に統一されました (#5080)

blog.shibata.tech

で触れた内容です。  

Get-Date-UFormatパラメーターのエラーメッセージが改善されました (#5055)

Get-Date -UFormat ''

の様に-UFormat''$nullを指定した場合、これまでのPowerShellではIndexOutOfRangeExceptionが発生してしまっていたのですが、PowerShell Core 6.0からは通常のパラメーターチェックエラーメッセージが出る様に改善されました。

コンソールコードのクリーンアップ (#4995)

こちらは元のPull Request(#4995)を見てもらうかない感じです。

PowerShell Coreの開発にあたって(主に.NET Coreで)サポートされない機能を削除しコードをクリーンアップしています。

主な変更点として、

  • pwsh起動時の-Sta-PSConsoleFile-Importsystemmodulesパラメーターの削除
  • コンソールフォント変更に関わるコード
  • #if CORECLRディレクティブの整理

が挙げられています。

RunspaceConfigurationサポートの削除 (#4942)

InitialSessionStateが導入されているためレガシーなRunspaceConfigurationは削除したとのことです。
この変更についてほとんどの人に影響はないと思います。
自作プログラム内からPowerShellをホストするケースでRunspaceConfigurationを使っている場合は影響が出そうですが正直なんともいえません...

PowerShellのコードからだと

$Host.Runspace.RunspaceConfiguration

$Host.Runspace.InitialSessionState

とするとそれぞれのプロパティにアクセスすることができます。
(だからどうしたという感じですが...)

CommandInvocationIntrinsics.InvokeScriptの引数が$argsでなく$inputにバインドされているのが修正されました (#4923)

正直、これは元のIssue(#4923)を見てもらうしかないでしょう...

PowerShell内部でスクリプトブロックを実行する際に$arg自動変数に設定すべき内容を$input自動変数に設定してしまっている不具合を修正したものだそうです。
GitHub上の会話を見る限りではこの誤った呼び方でスクリプトブロックが実行されるケースは少ないだろうとの判断で修正を入れています。

Get-Helpから-ShowWIndowパラメーターが削除されました (#4903)

-ShowWindowパラメーターで表示されるヘルプウィンドウはWPF製であり、.NET CoreでWPFはサポートされないための削除となります。

Remove-Itemでレジストリのパスを削除する際に*を受け入れる様になりました (#4866)

レジストリのパスには*が使用可能なのですが、PowerShellでは*はワイルドカードとして扱われてしまうためRemove-Itemが正しく動作しないケースがあり、PowerShell Core 6.0でこれが修正されています。

Set-Service-StartupTypeパラメーターの修正 (#4802)

元のタイトル*2がよくわからない感じなのですが、従来New-ServiceSet-Service-StartupTypeに不正な値を指定した際に無視されてしまう不具合があり、PowerShell Core 6.0では不正なパラメーターとしてエラーになる様に改善された様です。

$IsOSX自動変数が$IsMacOSに改名されています (#4700)

これはアルファ版からPowerShell Core 6.0を使っている人にしかわからないと思います。

当初macOSでの実行を判別するための自動変数は$IsOSXという名前だったのですが、開発中にOS XからmacOSにOSの名前が変更されたため$IsMacOSに改名されました。

GA後のPowerShell Core 6.0から使っている人であれば初めから$IsMacOSなので関係のないはなしになります。

pwsh起動時のパラメーター指定に関するエラーメッセージが改善されました (#4573)

元のタイトル*3が「お前は何をいっているんだ?」という感じなのですが、大元のIssue(#4351)を読む限りでは、pwsh(.exe)の起動時にあいまいなパラメーター名(-noだけなど)を指定した際のエラーメッセージが不親切であり、macOS版のPowerShellではエラーメッセージを出しつつも起動してしまうといった不具合があったため、不具合の改善に合わせてエラーメッセージの改善もした様です。

実際、

pwsh -no -command get-date

の様にあいまいなパラメーターを指定すると以下のエラーメッセージが表示されます。

PS C:\> pwsh -no -command get-date
Invalid argument '-no', did you mean:

  -nologo
  -noexit
  -noprofile
  -noninteractive

LocalAccountDiagnosticsモジュールのコマンドレットの削除 (#4302, #4303)

"PowerShell Coreでサポートされなくなった機能"の項で説明したMicrosoft.PowerShell.LocalAccounts*-Counter Cmdletsを削除した件のことです。

スクリプト実行時にBool型のパラメーターが有効にならないのを修正 (#4036)

これまでのPowerShellではpowershell.exeを起動する際のパラメーターにBool型の値を設定することができませんでした。

以下の様なbool型のパラメーターを持つスクリプトに対して、

# Test.ps1
param (
    [Parameter(Mandatory=$true)][bool]$BoolValue
)
Write-Output $BoolValue

パラメーターを指定して起動するとエラーとなりスクリプトは実行できません。

# Windows PowerShell
# 起動時エラーとなる
powershell.exe -File .\Test.ps1 -BoolValue $true

これまでは回避策として-Commandパラメーターを使うしかありませんでした。

# Windows PowerShell
# -Commandパラメーターで回避可能
powershell.exe -Command {.\Test.ps1 -BoolValue $true}

PowerShell Core 6.0ではこの点が改善され、bool型のパラメーターはSwitchパラメーターと同様の指定方法で設定することが可能になりました。

# PowerShell Core 6.0 からbool型のパラメーターも設定可能に
pwsh -File .\Test.ps1 -BoolValue:$true

$PSVersionTableからClrVersionプロパティを削除しました (#4027)

新機能まとめで説明した通りです。
PowerShell Coreの基盤である.NET Coreではこのプロパティの値が意味を成さなくなったため廃止されました。

pwsh(.exe)を起動する際の位置指定パラメーターは-Commandから-Fileになりました (#4019)

従来のPowerShellでは、パラメーター名を明示しない場合以下の様に

# -Fileパラメーター名を省略
powershell.exe .\hello.ps1

# -Commandパラメーター名を省略
powershell.exe "Write-Output 'Hello'"

-File-Commandの両方を位置指定パラメーターとして使えました。
PowerShell Core 6.0では主に非Windows環境のShebangからのPowerShell実行に対応するために位置指定パラメーターを-Fileのみに限定しています。

# PowerShell Core 6.0
# 〇 : -Fileパラメーター名は省略可
pwsh .\hello.ps1

# × : -Commandパラメーターは省略不可
pwsh "Write-Output 'Hello'"
# パラメーター名を明示する必要がある
pwsh -Command "Write-Output 'Hello'"
# -cでも良い
pwsh -c "Write-Output 'Hello'"

Unicode文字のエスケープが実装されました (#3958)

新機能まとめで説明した通りです。
`u#### または `u{####} でエスケープできます。

非Windows環境ではNew-ModuleManifestのエンコーディングがBOM無しUTF-8になります (#3940)

クロスプラットフォーム化対応の一環です。
New-ModuleManifestで出力されるマニフェストファイル(.psd1)のエンコーディングが、Windowsでは従来通りBOM付きUTF-16、非Windows環境ではBOM無しUTF-8になります。

Get-ChildItemはシンボリックリンクのリンク先を再帰検索しない様になりました (#1875, #3780)

Get-ChildItemの挙動をWindowsのdir /s、Unixのls -rと合わせるための仕様変更になります。
この変更があったため、これまでのPowerShellの挙動と互換をとるための-FollowSymLinksパラメーターが追加されています。(#3951)

Get-Content-Delimiterを指定した際にデリミタ自身が残ってしまう不具合が解消されました (#3706)

新機能まとめで説明した通りです。

Format-HexがC#で実装しなおされました (#3320)

もともとFormat-Hexはスクリプトコマンドレットだったのですが、機能追加の要望と併せてC#で再実装されることになりました。
この変更により-Rawパラメーターが存在はするものの何もしないパラメーターとなったため破壊的変更に加えられています。

ちなみに機能追加の要望はまだ取り入れられていません。

scriptコマンドでPowerShellが既定のシェルとして動作しない不具合を改善しています (#3319)

クロスプラットフォーム対応の一環です。
chshコマンドで既定のシェルをPowerShellに変えた後にscriptコマンドを実行するとPowerShellの起動に失敗する不具合があり、これを解消するためにpwsh(.exe)-Interactive(-i)オプションが導入されました。
従来のPowerShellには-NonInteractiveオプションがあり、これを逆転させた形となります。

Get-ComputerInfoで取得されるプロパティ名のTypoを修正 (#3167)

BiosSeralNumberBiosSerialNumberに修正されています。

Get-StringHashGet-FileHashの追加 (#3024)

Get-FileHashの改善の一環として新たにGet-StringHashコマンドレットを増やす提案がなされたのですが、要RFCということで導入は見送られています。
Get-FileHashから.NET Coreでサポートされなくなった、

  • MACTripleDES
  • RIPEMD16

のアルゴリズムが選択不可になっています。

幾つかのGet-*なコマンドレットで$nullが許容されていたのを廃止しました (#2672)

以下のコマンドのパラメーターで$nullが許容されていたのに対してValidateNotNullOrEmpty属性を付けてNULLチェックをする様になりました。

  • Get-Credential -UserName
  • Get-Event -SourceIdentifier
  • Get-EventSubscriber -SourceIdentifier
  • Get-Help -Name
  • Get-PSBreakpoint -Script
  • Get-PSProvider -PSProvider
  • Get-PSSessionConfiguration -Name
  • Get-PSSnapin -Name
  • Get-Runspace -Name
  • Get-RunspaceDebug -RunspaceName
  • Get-Service -Name
  • Get-TraceSource -Name
  • Get-Variable -Name
  • Get-WmiObject -Class
  • Get-WmiObject -Property

事の発端はこちらのUserVoiceからで、NULLを許容してしまうコマンドを洗い出しての修正となった様です。

Import-CsvにW3C拡張ログファイルのサポートが追加されました (#2482)

IISやExchangeで使われているW3C拡張ログファイルをImport-Csvで取り込める様になりました。
W3C拡張ログにはコメントヘッダーがあるため、ヘッダの取り扱いに破壊的変更が発生している様です。

ログファイル例)

#Version: 1.0
#Date: 12-Jan-1996 00:00:00
#Fields: time cs-method cs-uri

【2019.03.26追記】

ぎたぱそ先生の調査によりこの変更はExchangeログを対象にしていることがわかりました。

tech.guitarrapc.com

【追記ここまで】

関数の引数にValueFromRemainingArguments属性を付けた際のバインディングの問題 (#2035)

これは非常に説明しにくいのでもとのIssue(#2035)を見てください...
(私も完全に把握できていません...)

基本的にはValueFromRemainingArguments属性を付けたパラメーターに配列が渡されたときに、従来のPowerShellでは配列をまとめた形でバインドされるのですが、配列の要素ごとに展開すべきでは?という議論から始まっています。

ValueFromRemainingArguments属性を使うことはあまり無いと思いますので、ふつうにPowerShellを使う分には気にしなくても問題ないと思います。

$PSVersionTableからBuildVersionプロパティが削除されました (#1415)

新機能まとめで説明した通りです。
BuildVersionプロパティはWindowsのビルドと強く結びついているため廃止され、代わりにGitCommitIdプロパティが導入されています。

Web Cmdletsの変更

新機能まとめでも説明しましたが、PowerShell Core 6.0では基盤が.NET Coreになったこともあり、Web Cmdletsの基盤がWebRequestクラスからHttpClientクラスに代わっており、中身は完全に作り替えられています。
また、WindowsのWEBアクセス処理全般的な話としてIE*4に依存する部分があり、Windows PowerShellのWeb CmdletsにもIE依存な部分がありましたが、PowerShell CoreになってIE依存な処理が無くなったため、それがそのまま破壊的変更に繋がっています。

以下にInvoke-WebRequestInvoke-RestMethodの破壊的変更を記載します。

  • Invoke-WebRequestbasic HTML Parsingのみサポートします。(常に-UseBasicParsing指定と同等)
    これによりInvoke-WebReqestは常にBasicHtmlWebResponseObjectクラスのオブジェクトを返します。IEに依存するParsedHtmlオブジェクトは削除されました。
  • BasicHtmlWebResponseObject.Headersの値はstring型からstring[]に変更されました。

  • BasicHtmlWebResponseObject.BaseResponseSystem.Net.Http.HttpResponseMessage型のオブジェクトになりました。

  • 例外発生時のプロパティはSystem.Net.Http.HttpResponseMessage型のオブジェクトになりました。(参考)

  • -Headers-UserAgentパラメーターではRFCに厳密なヘッダ解析がデフォルトになりました。(参考)
    これを回避するには-SkipHeaderValidationパラメーターを指定します。

  • file://ftp://スキーマはサポートされません。(参考)

  • System.Net.ServicePointManagerクラスの設定は反映されなくなりました。(参考)

  • macOSでは今のところ証明書ベースの認証ができません。(#4650)

  • HTTP接続で-Credentialパラメーター使用した場合はエラーとなります。
    HTTPS接続にするか-AllowUnencryptedAuthenticationパラメーターを指定することでエラーを回避できます。

最後に

ざっとこんな感じです。
まだ正確に把握できていない箇所が残っているので分かり次第内容を更新していきたいと思います。

*1:当時はPowerShell Coreとは呼ばれていませんでしたが...

*2:Fix Set-Service failing test

*3:Make error message consistent when invalid script is passed to -File, better error when passed ambiguous argumen

*4:正確にはIEコンポーネントでしょうか