YaziをWindowsとWSL2で使い分けたら、file.exeでつまずいた

エクスプローラーを開いて、フォルダを何度も行き来する。嫌いではないのですが、コードを調べている途中に挟まると、そこで少し集中が切れます。

ターミナルの中でファイルを見て、そのまま移動して、次のコマンドへつなげたい。画面の中をhjklで動きながら、プレビューを見られるYaziはかなり好みでした。SF映画の端末を触っているようで格好いい、というのも正直あります。

WSL2側では素直に動きました。ところが別のWindows PCへ入れると、Yazi本体は起動するのにfile.exeがうまく使えません。プラグイン不足ではなく、Yazi本体、Git for Windowsのfile.exe、環境変数、設定ファイルを別々に確認する必要がありました。次に詰まったら、一つずつ切り分けます。

WindowsとWSL2へ入れた理由
fileはYaziのプラグインではなかった
Windows側の導入手順は、本体とfile.exeを分ける
設定ファイルはWindows用の場所へ、必要な分だけ置く
設定ディレクトリに本体ソースまで入っていた
WSL2側ではyを移動の入口にした
Yaziを入れた後の判断
確認した公式情報

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で実行します。YAZI_FILE_ONEはWindowsのユーザー環境変数として登録するもので、後述するyazi.tomlには書きません。file.exeを使うため、Git for Windowsが先に入っている前提です。

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"
if (-not (Test-Path -LiteralPath $file)) {
  throw "file.exeが見つかりません。Git for Windowsの場所を確認してください: $file"
}
& $file --version

バージョンが表示できたら、ユーザー環境変数へ登録します。途中で「file.exeが見つかりません」と止まった場合は、Git for Windowsの構成が異なる可能性があります。表示されたGitの場所と実際のfile.exeを確認してから、$fileへその絶対パスを入れ直します。

# Windowsのユーザー環境変数へ登録する
[Environment]::SetEnvironmentVariable("YAZI_FILE_ONE", $file, "User")

このSetEnvironmentVariableの実行が、環境変数を定義する操作です。WezTermを含め、開いているターミナルをいったん閉じてから開き直します。最後に次を実行すれば、本体とMIME判定用のコマンドを別々に確認できます。GetEnvironmentVariableは、登録した値を読み出しているだけです。

Get-Command yazi
yazi --version
$file = [Environment]::GetEnvironmentVariable("YAZI_FILE_ONE", "User")
if ([string]::IsNullOrWhiteSpace($file) -or -not (Test-Path -LiteralPath $file)) {
  throw "YAZI_FILE_ONEに有効なfile.exeが登録されていません"
}
& $file --version
$env:YAZI_FILE_ONE
if ($env:YAZI_FILE_ONE -ne $file) {
  throw "新しいPowerShellに届いたYAZI_FILE_ONEが保存値と一致しません"
}

環境変数は、開きっぱなしのWezTermには反映されません。Yaziだけでなく、WezTerm自体を閉じて開き直します。ユーザー環境変数の保存値だけでなく、新しく開いたPowerShellの値も確認します。最後の$env:YAZI_FILE_ONEが空、または保存値と違う場合は、新しいプロセスへ期待した値が届いていません。

別PCで失敗した時は、この確認結果を順番に残していませんでした。そのため、原因を環境変数の反映漏れとまでは断定できません。少なくとも、本体の起動、file.exeの存在、単体実行、再起動後の環境変数を分けて見れば、次はどこで止まっているか判断できます。

Git for Windowsを前提に、file.exeを見つける、ユーザー環境変数へ登録、WezTermを閉じて開き直す、本体・file.exe・値を確認 — Windows側の手順。途中でfile.exeが見つからなければ、登録へ進まずGitの場所を確認します。

設定ファイルはWindows用の場所へ、必要な分だけ置く

もう一つの落とし穴は設定場所です。ここから扱うyazi.tomlは、表示や並び順などYazi本体の動作を変えるためのファイルです。YAZI_FILE_ONEのような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のソースまで結果に混ざりました。設定だけを探したかったので、これはやりづらかったです。

起動エラーの原因ではありません。それでも設定、バックアップ、検索の邪魔にはなります。設定ディレクトリには設定だけを置く。移動や削除をする前に、Yaziの起動元や参照先になっていないことを確認します。

WSL2側ではyを移動の入口にした

WezTerm上では、Yaziを追加プラグインなしで起動してもPNGやJPEGをプレビューできました。公式ドキュメントを確認すると、YaziとWezTermがもともと対応している機能でした。

WSL2側では、終了後にYaziで開いていたディレクトリへシェルも移動するよう、公式のZsh用yラッパーを使っています。.zshrcへ入れている定義は次のとおりです。

Zsh用のyラッパーを表示する

function y() {
  local tmp cwd; tmp="$(mktemp -t "yazi-cwd.XXXXXX")"
  command yazi "$@" --cwd-file="$tmp"
  IFS= read -r -d '' cwd < "$tmp"
  [ "$cwd" != "$PWD" ] && [ -d "$cwd" ] && builtin cd -- "$cwd" || builtin true
  command rm -f -- "$tmp"
}

追記後は新しいシェルを開くか、source ~/.zshrcを実行してから使います。

これで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で読むへ続けます。

確認した公式情報

確認日: 2026年9月15日

Yazi Installation：Windows版Yazi、file.exe、YAZI_FILE_ONEの要件
Yazi Configuration Overview：WindowsとUnix系OSの設定ディレクトリ
Yazi Image Preview：WezTermでの画像プレビュー対応
Yazi Quick Start：Zsh用yラッパー