Windows のコマンドライン環境の整備

Windows 11 で PowerShell を中心としたコマンドライン環境を整えてみたので、忘れないうちに導入系のメモです。

昨今の Windows は winget コマンドでソフトウェアのインストールもアップグレードもできるので便利です。この記事でも導入に積極的に使っています。

https://learn.microsoft.com/ja-jp/windows/package-manager/winget/

winget コマンド ライン ツールを使用すると、Windows 10 および Windows 11 コンピューター上でアプリケーションを検出、インストール、アップグレード、削除、および構成することができます。 このツールは、Windows パッケージ マネージャー サービスに対するクライアント インターフェイスです。

winget で導入したパッケージの一括アップグレードコマンド:

# --accept-package-agreements はライセンス同意時に付与のこと
winget upgrade --all --accept-package-agreements

winget でパッケージを探す時のコマンド:

winget search Test #任意の文字列

ターミナル

ターミナルは (Windows) Terminal を使用。 導入:

winget install Microsoft.WindowsTerminal

PowerShell も WSL2 Linux も設定なしいけるので扱いやすいと思います。

設定フォント(PowerLine 含む)は HackGen NF を使わせていただいています。書体が綺麗でかつターミナルマルチプレクサなどを使ってもズレることもありません。

https://github.com/yuru7/HackGen/releases/tag/v2.9.0

白源 (はくげん/HackGen) は、プログラミング向け英文フォント Hack と、源ノ角ゴシックの派生フォント源柔ゴシックを合成したプログラミングフォントです。

外観設定:

Helix Editor の導入

ターミナル上で動作するスクリーンエディタである Helix Editor の導入。Rust でかかれています。なお、実行ファイル名は hx

https://helix-editor.com/

A post-modern text editor.

winget install Helix.Helix

モードがあるタイプの vim のようなテキストエディタで、標準で Language Server Protocol に対応しておりプログラミング向きです。

日本語入力についてはキャレットがずれてしまうなどがあり長文は厳しく、ソースコードコメント程度が入力できるかな、くらいで現在のところ考えた方が良さそうです。

使い方ですが、:tutor コマンドを入力するとチュートリアルファイルが開きますので、一通り下までやると覚えられると思います。また、操作に困った場合も、ESC, SPACE, ? するとファジーファインダー付きでアクションと操作一覧がでますので何とかなります。

vim から hx にくると手癖で苦戦するかもですが、、そうでなければ Helix のほうが操作系は統一されており、画面ヘルプも得やすいことから覚えやすいと感じました。(カーソルが単一幅の選択であり、x ではなく d なのだ、と念じて使うと分かりやすいす)

起動は hx . とカレントディレクトリを指定するとファイルピッカーが起動してくれます。(なお、ホームディレクトリなどファイル数が多いところで hx . をすると時間がかかるのでプロジェクトディレクトリまで cd した後に実行のこと)

複数ファイル編集時のバッファの移動は ESC, SPACE, b にて。プレビューもでて非常に便利です。

:config-open コマンドで Helix の主に見た目のコンフィグレーションをいくつかしています。設定ファイル保存後 :config-reload コマンドで即反映します。

theme = "dark_plus"

[editor]
cursorline = true
true-color = true
color-modes = true

[editor.soft-wrap]
enable = true

[editor.statusline]
right = ["diagnostics", "selections", "position", "total-line-numbers", "file-encoding", "file-type"]

[editor.file-picker]
max-depth = 6

[editor.indent-guides]
render = true
character = "│"

PowerShell 7 と Git と PowerLine と fzf とそれらの設定

PowerShell の 7 系を導入。 5 系と共存できます。

winget install Microsoft.PowerShell

PowerShell のコマンドプロンプトで PowerLine のような表示をする OhMyPosh と Git の導入。表示フォントは前述の HackGen NF を設定のこと。

# Git
winget install Git.Git
# OhMyPosh
winget install JanDeDobbeleer.OhMyPosh

ここで合わせて、コマンドラインでファイルのファジーファインドを行う fzf と PowerShell ラッパー PSFzf の導入。

PowerShell コマンドプロンプトから ctrl + t などの起動ショートカットにてインラインで画面が展開され、カレントディレクトリから再起でファイルを検索、補完入力できます。PowerShell でも便利。

# fzf
winget install junegunn.fzf
# fzf の PowerShell ラッパー
Install-Module -Name PSFzf -scope currentUser

PowerShell 環境のキーアサインや fzf の設定等々(fzf は Ctrl + t で起動するように):

# Helix で PowerSHell プロファイルを編集
hx $profile

# 以下内容 C:\Users\hiromasa\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
# oh-my-post のテーマは Get-PoshThemes で一覧できる
# oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\marcduiker.omp.json" | Invoke-Expression
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\paradox.omp.json" | Invoke-Expression

# Key アサインを Emacs 系に
Set-PSReadLineOption -PredictionSource History
Set-PSReadLineKeyHandler -Key Tab -Function Complete
Set-PSReadLineOption -EditMode Emacs
Set-PSReadLineOption -BellStyle None
Set-PSReadLineKeyHandler -Chord 'Ctrl+d' -Function DeleteChar

# PowerShell のエラー表示を簡素化
$ErrorView = "ConciseView"

# fzf
$Env:FZF_DEFAULT_OPTS = "--height=20 --border=sharp --layout=reverse"
Import-Module PSFzf
Enable-PsFzfAliases
# fzf を ctrl + t で起動
Set-PsFzfOption -PSReadlineChordProvider 'Ctrl+t' -PSReadlineChordReverseHistory 'Ctrl+r'

# Helix をデフォルトエディタに
$Env:EDITOR = "hx"

プログラミング言語

プログラミング言語として Rust と clang を導入。また、それぞれの周辺ツールや Language Server を構成。

# windows sysroot and toolchaine
winget install Microsoft.VisualStudio.2022.BuildTools
# clang 系
winget install LLVM.LLVM
# clang LSP
winget install LLVM.clangd
# make and cmake
winget install Kitware.CMake
winget install GnuWin32.Make
# Rust
winget install Rustlang.Rustup
rustup update
# Rust LSP
rustup component add rust-analyzer

コマンド検索 PATH 環境変数ぶ LLVM(clang)、CMake、make を追加。

C:\Program Files\LLVM\bin
C:\Program Files\CMake\bin
C:\Program Files (x86)\GnuWin32\bin

ここまで設定を進めて、ターミナルを再起動して PATH を反映すると Helix Editor で Language Server が動作するようになります。

Helix 構成確認:

> hx --health rust
Configured language server: rust-analyzer
Binary for language server: C:\Users\hiromasa\.cargo\bin\rust-analyzer.exe
Configured debug adapter: lldb-vscode
Binary for debug adapter: C:\Program Files\LLVM\bin\lldb-vscode.exe
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓
> hx --health c
Configured language server: clangd
Binary for language server: C:\Users\hiromasa\AppData\Local\Microsoft\WinGet\Links\clangd.exe
Configured debug adapter: lldb-vscode
Binary for debug adapter: C:\Program Files\LLVM\bin\lldb-vscode.exe
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓

Rust プロジェクトを hx で開くと Language Server が走って、入力補完や m コマンドのAST、g, d のシンボルジャンプなどが動作するはずです。うまくいかない場合は、:log-open コマンドでログを開くと解決のヒントがあるかもしれません。

clangd は CMake を構成して compile_commands.json をつくってもらえば include path などが解決されます。(簡単な構造のプログラムなら .json なしでよしなにしてくれるようです)

# for clangd (LSP)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

ちなみに Helix は Rust や clang ともに lldb-vscode で実験的ながらデバッグブレイクもできますが、自分が試した限り現時点の Windows 版ではまだうまく動作しないようでした。(止まるようで止まらない)ちなみにLinux だとブレイクと簡単なウォッチは大丈夫なので、おそらく近いうちに動作すると思います。

Linux 版 Helix で clangd を使って補完やデバッグブレイクしている様子:

gitui

Git のターミナルクライアントである gitui の導入。

winget install StephanDilly.gitui

gitui はキーボードのエンターキーや ESC キーで高速にぱちぱち動かせるので、オープンソースウォッチにも適しているのではないかと思います。

終わりに

普段は Linux を使っているので、実は今回調べてみるまで Windows でも fzf や gitui、 Helix がうまく動作すると知りませんでした。。てなわけで、簡単なコマンドラインツールを作りながら作業を進められるところまでいけたかなと思います。

PowerShell が割と久しぶりなので、また覚えながら。ちなみに Windows Terminal の次の次くらいのバージョンから PS の補完がドロップダウンで出力されるようです。楽しみ。

MINISFORUM UM690 の Windows 11 がダウンするようになった

これまで 8か月ほど調子良く動作していた MINISFORUM UM690 ミニ PC ですが、2023-9-13 くらいから Windows 11 使用中に真っ黒画面や画面の乱れの完全フリーズが数時間に一度発生するようになったのでメモ。

原因は不明でログとして。いろいろアップデートして様子見中(電圧降下等の外的要因の可能性もあり)

UPDATE – DDR5 SODIMM メモリーのハンダクラックが原因だったと思われます。

事象

発生時の画面: ちなみに白四角がライフゲームのように動いて焦りました。w

イベントログ: 同時刻に AUEPMaster.exe (おそらく RADEON の収集エージェント)のエラーが計上されている。

障害が発生しているアプリケーション名: AUEPMaster.exe、バージョン: 2310.31.1.824、タイム スタンプ: 0x64e76fbc
障害が発生しているモジュール名: ucrtbase.dll、バージョン: 10.0.22621.608、タイム スタンプ: 0xf5fc15a3
例外コード: 0xc0000409
障害オフセット: 0x000000000007f61e
障害が発生しているプロセス ID: 0x0x1D28
障害が発生しているアプリケーションの開始時刻: 0x0x1D9E791F01EAF58
障害が発生しているアプリケーション パス: C:\Program Files\AMD\Performance Profile Client\AUEPMaster.exe
障害が発生しているモジュール パス: C:\WINDOWS\System32\ucrtbase.dll
レポート ID: 36c9e805-9918-43b6-8267-82034cf2edbe
障害が発生しているパッケージの完全な名前: 
障害が発生しているパッケージに関連するアプリケーション ID: 

Windows Update 状況: (ちょうど 2023-09-13 にアップデートが当たっているが関連が思い浮かばず)

❯ Get-HotFix | sort -Descending InstalledOn

Source        Description      HotFixID      InstalledBy          InstalledOn
------        -----------      --------      -----------          -----------
MINIS-UM690   Security Update  KB5030219     NT AUTHORITY\SYSTEM  2023/09/13 0:00:00
MINIS-UM690   Update           KB5029921     NT AUTHORITY\SYSTEM  2023/09/13 0:00:00
MINIS-UM690   Update           KB5028756     NT AUTHORITY\SYSTEM  2023/08/11 0:00:00
MINIS-UM690   Security Update  KB5012170     NT AUTHORITY\SYSTEM  2023/01/16 0:00:00

BIOS: 1.11 12/15/2022 11:41:44

なお、VRAM 割り当てメモリーは 2G 設定。

いろいろアップデートしてみる

RADEON ドライバ更新: 23.8.2 -> 23.9.1

卵が先な感じもしますが AUEPMaster.exe をいったん disable に。AMD ユーザーエクスペリエンスプログラムを「辞退」に。(UPDATE – おそらく卵が先。後述の通りメモリーがエラーを起こしてエージェントがダウンを検知した気がします)

RADEON チップセットドライバ更新:

UM690 BIOS 更新: 6月に新しいのがでていたようだ。なお、Windows から BIOS 更新するため、更新中に事象が起きてダウンすると詰むかもなので注意(?)…(どきどきしました

更新後 – 1.17 x64 05/31/2023

ダウンロードリンク

RADEON & チップセットドライバー

https://www.amd.com/en/support

Auto-Detect and Install Driver Updates for AMD Radeon™ Series Graphics and Ryzen™ Chipsets

MINISFORUM UM690 BIOS

https://www.minisforum.jp/support/55

UM690 ダウンロード先 BIOS F7BFC_1.17

対応結果

RADEON & チップセット & BIOS のアップデートを行い様子見中。果たして…

2023-09-15 追記(1)

アップデート後、ダウンしないものの描画がおかしくなっているのを発見(メモリー壊れてる?)

Windows 標準のメモリー診断を実行。GPU 共有メモリーが診断に含まれるか分からなかったのでいったん VRAM 512MB の最小構成で実行。問題なしで申告された。

2023-09-16 追記

Windows 起動中に GPU にメモリーを使わせるなどしていたら、画面がちらついた後 BSOD 発生。(ほぼほぼ確定で飛ぶっぽい)

BSOD せずに RADEON ドライバーが例外をキャッチするケースもあり。

同じ矩形の大きさで画面が崩れてクラッシュするケース。

memtest86 実行。美しい感じでフェイル。DDR5 メモリーが壊れたのが原因とあたりをつける。(16G * 2枚刺しなので 1枚ごとに後日やってみる)

ちなみにメモリーチェックフェイル申告後にリブートしてしまう。(フェイル画面を見るのが大変でした)

2023-09-16 追記 (2)

UM690 は開けやすくて good。なお本機は蓋についてる SATA 2.5 inch アタッチメントに SATA SSD を自分で追加して使っています。放熱やエアフローに影響しているかもしれません。

メモリーを片側、スロットを交互に計 4回で memtest86 を実行。スロット関わらず片方の SODIMM メモリーでのみメモリーチェックのフェイルが発生。ソケットやバスは問題なしと判断。

というわけで、UM690 のクラッシュの原因はメモリー故障と判断して良さそうです。このモジュールを交換すれば直ることでしょう(解決

memtest86 の温度設定

memtest86 実行中で Temp の最大温度が低くとられるケースがあったので <F6> Temperature disble を設定。(通常は 83度で取れるが 65度とかになることがあった)

おまけ

以下は特別な訓練によりメインボード等を壊す覚悟ができているひろましゃが自己責任を前提に行っています。

不良と判断した DDR5 SODIMM モジュールに対してヒートガンによるリフローを実施。フラックス塗布後、左右で 1分程度炙りました。このことにより、メモリーチェックがパスするように。また、記事中に記載した全ての不具合が再現しなくなりました。

memtest86 によると、メモリー高負荷時に温度が 80度前後まで上がるようなので、SODIMM にヒートシンクなどを付けたほうがいいのかもしれません。

Ubuntu コンテナの日本語フォントをデスクトップ版と合わせる

コンテナー版の Ubuntu は日本語フォントのデフォルトが通常の日本語設定されたデスクトップ版の Ubuntu と異なっており、特にシステム日本語フォントを使って処理をする帳票などで出力が異なる動作となる場合があります。

今回は、UML 画像の出力を行う Java の PlantUML ライブラリにて、デスクトップ版とコンテナ版の Ubuntu 22.04 でレンダリングに差異がでるという事象として確認しました。

具体的には、デスクトップ版 ja_JP.UTF-8 設定の Ubuntu 22.04 では正しく PDF レンダリングができる Asciidoc/PlantUML 文書を、GitHub Actions 上の Ubuntu コンテナでビルドさせると「日本語フォント幅が短くなって崩れる」対応になります。(この事象は、WSL2 上で動作する Ubuntu 22.04 のデフォルト状態でも発生すると思います)

PlantUML の出力する SVG の日本語フォント部分の幅計算がおかしくなるの図:

調べてみると PlantUML はデフォルトで sans-serif などのデフォルトフォント名をもとにフォント幅を計算するようでした。(追記)PlantUML のデフォルトフォントは Dialog のようです。

コンテナとデスクトップ版で fc-match を比較。

# デスクトップ版 Ubuntu
$ fc-match sans-serif
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"
$ fc-match Dialog
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"
# コンテナ版 Ubuntu
$ fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match Dialog
DejaVuSans.ttf: "DejaVu Sans" "Book"

というわけで、PlantUML にレンダリングシステムフォント名を指定するか、sans-serif などの標準的なフォント名を Noto Sans CJK JP で引けるようにするかで解決しそうです。今回は後者の方法を選択しました。

コンテナ版 Ubuntu で次のようにするとデスクトップ版と同じように sans-serifNoto Sans CJK JP になります。

apt-get -y update
apt-get -y upgrade
apt-get -y install language-pack-ja fonts-noto* fontconfig language-selector-common
update-locale LANG=ja_JP.UTF8
fc-cache -f # 念の為

LANGja_JP.UTF-8 の場合に Noto Sans CJK JP が選択されるように language-selector が組まれています。

$ export LANG=ja_JP.UTF-8
$ fc-match sans-serif
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"
$ fc-match Dialog
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"
$ export LANG=C
$ fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match Dialog
DejaVuSans.ttf: "DejaVu Sans" "Book"

なお、コンテナ全体の LANG 設定は大きな変更となりますので、既に動作しているコンテナの場合は、起動するアプリケーションごとに範囲を絞って設定したほうが良いかもしれません。

GitHub Actions の該当部分:

    - name: Setup Environment (Ubuntu)
      if: startsWith(matrix.os, 'ubuntu')
      run: |
        sudo apt update
        sudo apt upgrade
        sudo apt install language-pack-ja-base language-pack-ja
        sudo update-locale LANG=ja_JP.UTF8
        sudo apt install fonts-noto* language-selector-common
        export LANG=ja_JP.UTF-8
        fc-cache -f
        fc-match Dialog | grep "Noto Sans CJK JP"

また、クラウド IDE である Gitpod のコンテナでは初期化を次のようにすると内部ターミナルの再起動を行って場合でも LANG が設定されるようにできます。

image: gitpod/workspace-full
tasks:
  - name: Setup
    before: |
      sudo apt-get -y update
      sudo apt-get -y upgrade
      sudo apt-get -y install language-pack-ja graphviz fonts-noto* language-selector-common
      sudo update-locale LANG=ja_JP.UTF8
      echo 'export LANG=ja_JP.UTF-8' >> ~/.bashrc
      export LANG=ja_JP.UTF-8
      fc-cache -f
      fc-match Dialog | grep "Noto Sans CJK JP"

そんなこんなで、GitHub Actions 上で Ubuntu, Windows, macOS の 3環境 x Java 11, 17 の 2環境、合計 6 環境で Asciidoc/PlantUML 文書のビルド・テストができるようになりました。良い。:D

今回の例だと本来的には、SVG を PDF にレンダリングするフォントと、

  • 各 OS の Dialog フォント設定を一致させるか、
  • PlantUML 自体に Dialog ではなく、PDF レンダリングフォントを使うように指示して フォント幅計算をさせる

のが正しい処理と思いますが、各環境のビルド結果の PDF 文書を目視したところ、確認できるような差異がでていないのでいったんヨシとしています。

関連