WSL の内側の世界から、外側の Windows の世界の PATH が "何もしていないのに" 通っている件、をどうにかしたい場合のメモ
WSLの内側の世界では、外側の世界の Windows で実行可能なバイナリー「も」実行できます。
実際この機能はしばしば便利な事もあります。例えば、
- 諸事情によりWSLの内側の世界で作業中に
PE32+(†1) なバイナリーファイルをnm(†2) したいけどELF(†3) じゃないのでもちろんできないので- 仕方がないので
dumpbin(†4) しなければならないが - わざわざWSLの外側の世界で
cmdやpowershellで実行するのは面倒 (†5)
みたいな事が起こるユーザーにはとても便利です。 PATH 通すか alias や function で呼べるようにしておけばね💪
- (†1): https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
- (†2): https://linux.die.net/man/1/nm
- (†3): http://refspecs.linuxbase.org/elf/elf.pdfhttps://en.wikipedia.org/wiki/Executable_and_Linkable_Format
- (†4): https://docs.microsoft.com/en-us/cpp/build/reference/dumpbin-reference
- (†5): Powershell と Windows のウィザードなら面倒な世界が逆転するかもしれません。
そういうわけで PATH の話に無理やり繋げました。 WSL の内側の世界では Windows (のWSLの仕組み) が "気の利かせ" て Windows の世界の PATH を WSL の内側の Linux の世界へ全自動デフォルトで注入してくれます。野暮なお節介ババア的な感じで。すごくいい人だけどいい人すぎて余計なお世話のトラブルメーカー的な。
つまりこういう事が起こる:
- WSL の内側の世界でプラットフォームのパッケージマネージャーを介して
yarnを入れてあるとしましょう:
<< which yarn /sbin/yarn
- その
yarnのglobal bin置き場は default な具合でこうなっていて、なにか適当なアプリが入っていたとしましょう (↓の例ではneon; 例なのでなんでもいいです ):
<< yarn global bin --offline /home/usagi/.yarn/bin << ll $(yarn global bin --offline) total 8.0K drwxr-xr-x 2 usagi usagi 4.0K 2020-03-22T13:20:24 ./ drwxr-xr-x 3 usagi usagi 4.0K 2020-03-20T22:04:21 ../ lrwxrwxrwx 1 usagi usagi 48 2020-03-22T13:20:24 neon -> ../../.config/yarn/global/node_modules/.bin/neon
- ところがこの
yarnを介して導入したはずのアプリを実行すると何か奇妙な現象に見舞われて、原因を探るためにまずwhichとかreadlinkとかheadかhexdump…
<< which neon /mnt/c/Users/usagi/AppData/Local/Yarn/bin/neon
／(^o^)＼
みたいな事が起こります。起こりました。単独で他のファイルに絡まずに実行可能なスクリプトでは実害のある問題は起こらない事もありますが、そうではない場合はわりと危険が危ないです。これについて、ぱわーのあるユーザーなら PATH について .zshrc 的ないつものところへ PATH=$( 💪 MY AWESOME BLACK MAGIC BE DESTROY AUNT MEDDLESOME WINDOWS GIVEN HOLY PATH 💪 ) みたいなみなぎる筋肉をぶつけていくスタイルでマッチョに解決していた時代も実際あったようです。 perl でも php でも awk でも python であれ、何か得意な黒魔術で対処療法の時代。
現在は既に対処療法ではなく遺伝子操作やワクチンによる解決が実用可能になっていて:
WSL 内へ摂取する"ワクチン的"でお手軽な方法として:
/etc/wsl.confを書く:
[Interop] appendWindowsPath = False
- 管理者権限の
powershellでRestart-Service LxssManagerしておく ( 全ての WSL 環境は安全に閉じてから↑の設定後に1回する )
これだけでよくなったようです。🎉
外の世界の Windows のお節介による PATH が消えたので先の例の WSL 内 yarn を介して導入した neon が which でも確認できるようになりました。 yarn だけなら💪的に export PATH="$(yarn global bin --offline):$PATH" だけでも事実上は解決できるのだけど、それだけ、という事ではなく解消しておきたい場合には一般的に WSL のお節介機能を無効化するのが安全です。
"遺伝子操作"的なやつがお好みの場合は regedit して HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss のなかをもぞもぞする方法もあるようです。私は楽にすませたいので /etc/wsl.conf したのでこちらは試しませんでしたけれど。
