WSLとWindowsの環境変数

昨夜、久し振りにWSLのOracle Linuxを起動したのですが、シェルの立ち上がり時にエラー（とは言っても、致命的なエラーではなく、コマンドが無い的なもの）。見ると、Pyenvの実行でエラー。ただ、エラーに出ているパスを見ると「/mnt/d」で始まっている。「？」と思った。「/mnt/（c以降のアルファベットの一字）」で始まるパスって、Windowsのドライブ以降を指すんですよね。「Linux環境側でなんでWindowsのドライブ参照してるの？」と思い、Oracle Linux側で環境変数PATHの内容を表示させると、かなりの量のパス情報が入っていました。で、見てみると、Windowsの環境変数PATHに設定している内容と同じものが多数。この時点で、Windowsの環境変数を取り込んでいるのだなと判断。マイクロソフト製品での話ということで、copilotで「WSLのLinux側の環境変数にWindowsの環境変数を引き込まないようにするには」で聴いてみました。
回答は即さま出て来て、内容としては、「/etc/wsl.conf」に下記の内容を追加するというものでした。

[interop]
enabled=false

[environment]
appendWindowsPath=false

実際、この通りに追記し、WSLを再起動したところ、状況は変わらず。何度やってみても変わらず、環境変数PATHを表示させても、Windows側の環境変数が取り込まれたままでした。PC自体再起動すれば変わるかなと思い、昨夜は試行を止めて、シャットダウンしました。

日が変わって今日。昼間、時間があったので、PCを立ち上げ、再度WSLを起動。しかし、結果は変わらず。エラーは出るし、環境変数PATHもWindows側の内容を取り込んでいた状態でした。とりあえず、Oracle Linux側でpyenvは使わなくてもいいやと思ったので、一旦、pyenv環境を凍結（.bash_profileからpyenv関連をコメントアウト。pyenv環境のディレクトリをリネーム）。ここでWSLを再起動したところ、エラーは出ませんでした。しかし、環境変数PATHにはWindowsの環境変数が取り込まれているのはそのまま。
そもそも、「Linux環境にWindows環境の環境変数取り込む必要ないよね」と思い、再度検索。今度はcopilotではなく、Google検索で検索しました。検索結果を見たところ、ほぼほぼ同内容。やり方は間違ってないのかと思ったが、よくよく見ると、微妙に違う。ググった結果では

[interop]
appendWindowsPath = false

falseを設定するプロパティは同じ（appendWindowsPath）なのだが、セクションが異なる。copilotの回答では、appendWindowsPathは[environment]の下にあったが、ググった結果は[interop]の下。ものは試しに、appendWindowsPathの設定を[interop]セクションの下に移動。WSLを再起動し、環境変数PATHの内容を表示。確認すると、Windows側の定義は消えており、Linux側の設定だけのスッキリとしたものに（笑）。
そこで、先ほど凍結したpyenvの環境を復帰。.bash_profileのコメントを外すのと、ディレクトリ名を戻しただけなので、WSLの再起動はせずに、新たにOracle Linuxのシェルのウィンドウをオープン。するとエラーも出ず、pyenvもLinux環境側の実行ファイルを実行し、正常に動作しました。

マイクロソフトの製品だからということで、copilotで問い合わせたところ、回答が微妙に違っていました。結果としては、Google検索の結果で解決できました。そこで、「他のAIだとどんな回答を返すか」という疑問が湧き、GoogleのGeminiとXのGrokで同じ内容で問い合わせてみた。
まずはGoogleのGemini。これはGoogle検索と同じ回答が返ってきました。まあ、検索がGoogleだからこれは当たり前かなと。続けてXのGrok。こちらもGoogle検索と同じ結果。皮肉にも、マイクロソフト製品のことを聞いているのに、copilotだけが異なる回答（しかも微妙に違うという）を返すという結果となりました。
同社製品のAIアシスタントの回答でも、鵜呑みにせず、調べた結果が期待通りでない場合、他の検索方法で調べるのが肝要ですね。その方が早く解決できるという一例でした。