PowerShell 7.1に導入された実験機能 - PSNativePSPathResolution

PowerShell 7.1が公開された。PowerShell 7.1自体は漸進的なリリースとなっており、細かい変更や改善などを取り込んだバージョンである。機能的に大きな変更や追加が行われたPowerShell 7.0と比べると、かなりおとなしい印象だ。

今回は、PowerShell 7.1に正式に導入された実験機能から「PSNativePSPathResolution」を取り上げようと思う。実験機能は今後取り込まれる可能性があるため、今後登場するPowerShellの機能を予測する上で役に立つ。

実は以前に一度、PSNativePSPathResolutionについては取り上げているのだが、PowerShell 7.1で正式な実験機能として取り入れられた今、今後WSLとの連携などが進んでいく上でも気になる部分なので、ここでおさらいをしておこう。

PowerShellではFileSystemプロバイダによって「C:」や「D:」、「Temp:」といったパスが使用できるようになっている。また、ホームディレクトリの記述方法として「~」も使用できる。

これらのパスはPowerShellコマンドレットが扱う分には問題ないのだが、Windowsのネイティブコマンドで使おうとすると問題が発生する。ネイティブコマンドは、こうしたPowerShellで使われているパスには対応していないためだ。

PSNativePSPathResolutionはこの部分のギャップを埋めるパス変換機能だ。PowerShell 7.1ではこの機能はデフォルトで無効化されている。

この機能は「Enable-ExperimentalFeature -Name PSNativePSPathResolution」のようにコマンドレットを実行することで有効化できる。

ただし、上記スクリーンショットのメッセージに示されているように、この機能は次にPowerShellを起動した段階で機能が有効になる。このため、いったんPowerShellを終了して、再度PowerShellを起動する。すると、次のようにPSNativePSPathResolutionが有効になったことを確認できる。

では、動作の比較を行ってみよう。次のスクリーンショットはPSNativePSPathResolutionが「無効」の状態のPowerShell 7.1で実行したものだ。「~/」や「Temp:」を含むパスをネイティブコマンド、ここでは「notepad.exe」に渡している。

実行すると、次のようにエラーが表示される。notepad.exeにそのまま「~\test.txt」や「Temp:\test.txt」といったパスが渡っており、当然Windowsコマンドではこんなパスは処理できないので、結果としてエラーが表示される。

今度はPSNativePSPathResolutionを有効にしたPowerShell 7.1で同じことをやってみる。

次のようにWindowsのネイティブコマンドが理解できる状態にパスが変換／実行されていることがわかる。

なお、パス変換を行わずにコマンドに渡したい場合には、パス自体をシングルクォーテーションで囲えばよい。

Microsoftはコマンドプロンプトを互換性の目的のみで提供しており、今後はPowerShellを使ってほしいと呼びかけている。となると、WindowsのネイティブコマンドはPowerShellから実行するのが推奨される使い方ということになる。当然、PowerShellで使われるパスがWindowsのネイティブコマンドでも使えることが望ましい。PSNativePSPathResolutionはこれを実現するための機能だ。特に問題はないように見えるので、このまま将来のバージョンで正式な機能として取り込まれるのではないかと思う。

WSL用のパス変換機能がほしい

PSNativePSPathResolutionはPowerShellで使われるパスをWindowsのネイティブコマンドで使えるパスに変換するものだ。できれば、同じような機能がWSLで動作するコマンドに対しても使えるようになると便利だ。

wslコマンドを使えば、PowerShellからWSL経由で動作するLinuxのコマンドを実行することができる。しかし、パスの変換は行われないので、パスに関しては自分で変更する必要がある。PSNativePSPathResolutionと同じような機能をWSL環境内のコマンドに対しても使えるようになると、もっとPowerShellとWSLの連携を進めることができて便利だ。

本連載ではこの部分の変換を自前の関数で作成したわけだが、デフォルトの機能として用意してくれたほうが助かる。この機能が利用できると、Windows側のファイルシステム上のファイルやディレクトリに対し、パスの違いなどを気にすることなくWSLで動作するコマンドを実行できるようになって便利だ。ファイルシステムはWindows 10ネイティブ、コマンドはWSLだ。Windows風パスとLinux風パスが混ざっても動くと、かなりストレスがなくなる。この組み合わせはなかなか便利なので、将来的にはここまで用意されることを期待したい。

PowerShell 7.1の対応プラットフォーム

前回までにPowerShell 7.1のインストール／アップデート方法を取り上げたが、サポートしているプラットフォームについて、ここで補足しておこう。本稿執筆時点でMicrosoftはPowerShell 7.1は、サポートするOSとして次のプラットフォームを挙げている(アーキテクチャ指定がないものはx64）。

• Windows 10 (ARM64)
• Windows 8.1 (ARM64)
• Windows 10
• Windows 8.1
• Windows Server Semi-Annual Channel (SAC)
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Ubuntu 20.04
• Ubuntu 18.04
• Ubuntu 16.04
• Ubuntu 20.04 (ARM64)
• Ubuntu 18.04 (ARM64)
• Ubuntu 16.04 (ARM64)
• Ubuntu 19.10
• Debian 10
• Debian 9
• RHEL 8
• RHEL 7
• CentOS 8
• CentOS 7

Microsoftがサポートしているわけではないが、コミュニティによってサポートされているプラットフォームとして次のOSも挙げられている。

• Fedora 32
• Alpine 3.11+
• Alpine 3.11+ (ARM64)
• macOS 10.13+

Linuxディストリビューションに関しては、実際にはこれら以外のプラットフォームでも利用できるし、ARM32などのプラットフォームでも動作するものがあるとされている。

注目しておきたいのは、ARM64版が提供されている点だ。AppleがApple M1チップを搭載したMacの販売を開始しており、開発者はかなり早い段階でこのハードウエアへ移行する可能性がある。まだMicrosoftが態度を明らかにしていないため不透明なのだが、MicrosoftがARM版Windows 10の提供を開始すれば、Apple M1を搭載したMacの仮想環境でWindows 10 (ARM64)を使う開発者が出てくるのは間違いない。だとすると、すでにPowerShell 7.1がARM64に対応しているというのは価値があるのだ。