改行コードはCRLFにします

気が付きにくい罠なのですが、改行コードはLFではなくCRLFにしましょう。

例えば以下のようなPowerShellスクリプトを書いた場合、

# `stable`ブランチに切り替え、存在しない場合は`origin/stable`から作成します。
if ($null -eq (git branch --list stable)) {
    git switch -c stable origin/stable
}
else {
    git switch stable
}

PowerShell 5で実行すると、

PS C:\Users\ncaq\Downloads> .\play.ps1
発生場所 C:\Users\ncaq\Downloads\play.ps1:3 文字:1
+ }
+ ~
式またはステートメントのトークン '}' を使用できません。
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : UnexpectedToken

のようにエラーが出ます。

何故かと言うと、コメントが正常に改行で終了してない扱いになるみたいですね。なので2行目などがなかったことになります。

コメントを含まないスクリプトの場合動いたり動かなかったりします。少し謎です。

パースエラーのエラー表示ではご覧のように改行されて出力されるので気がつくのが遅れました。

ちなみにPowerShell 7だと正常に実行出来ます。

文字コードはUTF-8にする場合BOMをつけます

Windows向けだろうと流石にUTF-8でソースコードは記述したいものです。

PowerShell 7では自動で認識するようです。

しかし、 Windows 10/11で標準で実行されるPowerShell 5では、 UTF-8にBOMが無いと日本語Windowsでは認識されるのか、 Write-Hostなどで文字化けが発生します。

BOMをつけるとちゃんとUTF-8で書かれていると認識して出力してくれます。

chcpとかでガチャガチャするより大多数のシステムの類推で動くように任せるほうがまだ安心できますね。

Emacsならばset-buffer-file-coding-systemでutf-8-with-signature-dosを選択しておけば良いでしょう。

頻繁に忘れるのでEmacsのinit.elで設定してしまっても良いかもしれませんね。

.editorconfigの設定

次から間違えることを防止するために.editorconfigを設定しておきましょう。

プロジェクト全体ではcharset = utf-8, end_of_line = lfを設定しているので尚更です。

[*.bat]
end_of_line = crlf
charset = latin1

[*.ps1]
end_of_line = crlf
charset = utf-8-bom

署名のないPowerShellスクリプトがWindowsの設定次第で実行しづらいことに対処するために、同名のバッチファイルを作ってPowerShell -NoProfile -ExecutionPolicy Unrestrictedで実行するテクニックを使っているので、バッチファイル向けの設定もしています。

コマンドプロンプトのバッチファイルのUTF-8へのスマートな対応には全く期待してないのでユニコード文字は不許可にしています。

どうせPowerShellを起動する単純なスクリプトしか書かないのでcharset = latin1としています。これはASCIIと入力したかったのですが、 EditorConfig Properties · editorconfig/editorconfig Wiki を見てもus-asciiとかが存在しなかったので妥協しました。サポートしている実装はそれなりにあるのかもしれませんが。

とりあえず日本語圏では日本語を入力させないというだけでそれなりの働きはしてくれると思います。

はてなブックマークのコメントによる補足: PowerShell 7の互換性はまだまだらしい

PowerShellのスクリプトを書く時の諸注意

PowerShell7以降(pwsh)は、Windows PowerShell(いわゆる5.1)のモジュールが全然入ってない別物。故に7系はPowerShellの中心的なニーズであるWindowsの管理系作業では使い物にならない。7系がデフォルトになんて今の段階じゃあり得ん。

2023/07/29 20:08

なるほど、

Windows 管理モジュールでは、Windows のさまざまな機能やサービスの管理とサポートが提供されます。 これらのモジュールのほとんどは、PowerShell 7 でネイティブに動作するように更新されているか、PowerShell 7 との互換性がテストされています。

PowerShell 7 モジュールの互換性 - PowerShell | Microsoft Learn

とか書かれていたので殆ど互換性があるものかと考えてしまいましたが、まだまだモジュールの互換性が取れてないんですね。

具体的にどういうものが互換性が取れてなくてクリティカルに不便なのかは、 PowerShell 7 module compatibility | Microsoft Learn を見てもそんなにWindowsに詳しくない私にはすぐにはピンと来ませんでしたが。

コア部分での互換性は取れているはずなので、互換レイヤーでのモジュール対応も含めて、コーナーケースをひたすらに潰していったらいつか置き換わる日がくるかもしれませんね。 Microsoftもいつまでも2つの.NET、 2つのPowerShellをメンテナンスするのは嫌だと思うので。