エクスプローラーを開いて、フォルダを何度も行き来する。嫌いではないのですが、コードを調べている途中に挟まると、そこで少し集中が切れます。
ターミナルの中でファイルを見て、そのまま移動して、次のコマンドへつなげたい。画面の中をhjklで動きながら、プレビューを見られるYaziはかなり好みでした。SF映画の端末を触っているようで格好いい、というのも正直あります。
WSL2側では素直に動きました。ところが別のWindows PCへ入れると、Yazi本体は起動するのにfile.exeがうまく使えません。プラグイン不足ではなく、Yazi本体、Git for Windowsのfile.exe、環境変数、設定ファイルを別々に確認する必要がありました。一つずつ切り分ける。いまの結論はそれです。
WindowsとWSL2へ入れた理由
開発の中心はWSL2です。それでも別PCのWindows側へYaziを入れたのは、WezTermからPowerShellを使う時も同じ操作感でファイルを探したかったからです。
同じYaziでも、実行ファイルと設定はWindows用とWSL2用で別々に持ちます。二重管理を増やしたいわけではなく、どちらのターミナルでもhjklで動きたい。それだけです。
fileはYaziのプラグインではなかった
最初に混乱したのはfileです。名前だけ見るとYaziのファイル用プラグインのように見えますが、これはファイル種別を判定する外部コマンドです。
Yaziの公式インストール手順でも、MIMEタイプ判定のためにfile(1)が必須とされています。Windowsでは、Git for Windowsに含まれるfile.exeを使い、YAZI_FILE_ONE環境変数で場所を指定します。
YAZI_FILE_ONEへ指定する値は、次の形になります。
<Gitのインストール先>\usr\bin\file.exe
Windows側の導入手順は、本体とfile.exeを分ける
公式手順では、Windows版YaziをWinGetから入れられます。以下はPowerShellで実行します。
winget install --id sxyazi.yazi --exact
次に、PowerShellから見えているgit.exeを表示します。これでGitのインストール先を確認できます。
$gitExe = (Get-Command git -ErrorAction Stop).Source
$gitExe
通常は<Gitのインストール先>\cmd\git.exeのように表示されます。標準的な構成なら、そこからfile.exeの場所を組み立てられます。
$gitExe = (Get-Command git -ErrorAction Stop).Source
$gitRoot = Split-Path (Split-Path $gitExe -Parent) -Parent
$file = Join-Path $gitRoot "usr\bin\file.exe"
$file
Test-Path $file
& $file --version
Test-PathがTrueになり、バージョンも表示できたら、ユーザー環境変数へ登録します。
[Environment]::SetEnvironmentVariable("YAZI_FILE_ONE", $file, "User")
WezTermを含め、開いているターミナルをいったん閉じてから開き直します。最後に次を実行すれば、本体とMIME判定用のコマンドを別々に確認できます。
Get-Command yazi
yazi --version
$file = [Environment]::GetEnvironmentVariable("YAZI_FILE_ONE", "User")
Test-Path $file
& $file --version
環境変数は、開きっぱなしのWezTermには反映されません。Yaziだけでなく、WezTerm自体を閉じて開き直します。
別PCで失敗した時は、この確認結果を順番に残していませんでした。そのため、原因を環境変数の反映漏れとまでは断定できません。少なくとも、本体の起動、file.exeの存在、単体実行、再起動後の環境変数を分けて見れば、次はどこで止まっているか判断できます。
設定ファイルはWindows用の場所へ、必要な分だけ置く
もう一つの落とし穴は設定場所です。公式の設定ドキュメントによると、WSL2では~/.config/yazi/、Windows版では%AppData%\yazi\config\を使います。同じyazi.tomlでも、WSL2側へ置いたものをWindows版が自動で読むわけではありません。
PowerShellでは$env:APPDATAから作れば、ユーザー名を含む絶対パスを手で書かずに済みます。
$configDir = Join-Path $env:APPDATA "yazi\config"
New-Item -ItemType Directory -Force -Path $configDir
explorer $configDir
Yaziは設定ファイルがなくても基本操作ができます。自分で変えたい項目だけをyazi.tomlへ書けば十分です。Windows側では、次の内容を%AppData%\yazi\config\yazi.tomlへ置きます。
# yazi.toml
[mgr]
ratio = [1, 4, 3]
sort_by = "alphabetical"
sort_dir_first = true
show_hidden = true
[preview]
image_delay = 30
image_quality = 75
設定ディレクトリに本体ソースまで入っていた
WSL2側の設定を確認すると、~/.config/yazi/yaziの下にYazi本体のGitリポジトリまで残っていました。約15MBあり、rgで設定を探した時にはRustのソースまで混ざって3,000行以上がヒットしました。
起動エラーの原因ではありません。それでも設定、バックアップ、検索の邪魔にはなります。設定ディレクトリには設定だけを置く。このソースは動作への影響を確認してから別作業で移す予定です。
WSL2側ではyを移動の入口にした
WezTerm上では、Yaziを追加プラグインなしで起動してもPNGやJPEGをプレビューできました。公式ドキュメントを確認すると、YaziとWezTermがもともと対応している機能でした。
WSL2側では、終了後にYaziで開いていたディレクトリへシェルも移動するよう、公式のZsh用yラッパーを使っています。
y
これでYaziを閉じた後に、表示していたディレクトリで次のコマンドを実行できます。単にファイルを眺めるだけでなく、移動の入口として使えるのが便利でした。
Yazi内では、次の操作をよく使っています。
s：fdでファイル名を探すS：ripgrepでファイル内容を探すz：fzfで絞り込むZ：zoxideの履歴からディレクトリへ移動する
fd、rg、fzf、zoxideはYaziとは別のコマンドです。Windows側でも同じキーを使うなら、そちらにも各コマンドが必要になります。
Yaziを入れた後の判断
Yaziを入れたことで、ファイル操作が何倍も速くなったわけではありません。変わったのは、ファイルを探すためにターミナルから離れなくなったことです。見て、選んで、その場所で次のコマンドを打てる。この流れが気に入っています。
Windowsで詰まった時に、Yaziへ別のプラグインを足そうとしたのは遠回りでした。見るべきだったのはfile.exeの場所と環境変数です。本体、外部コマンド、設定ファイル。似て見えても、分けて確認する。次のPCでは同じところをぐるぐる回らずに済みそうです。
このYaziをNeovimやrgとどうつないでいるかは、AIにコードを書かせた後、rg・fzf・Yazi・Neovimで読むへ続けます。
コメント