先天的迷子満載感。
WSL = 「Windows Subsystem for Linux」…の細かい話はおいおいで、という前置きは昨日のと同じ。
典型的・日常的、という「普通の」使い方は、ホスト(Windows)の PowerShell コンソールから「wsl コマンド」を介して例えば「wsl ls」のようにアクセスするか、例えば ubuntu.exe を起動して「清く正しい linux を使っているつもりになって使う」か、Docker を介して使うか、の三つ。けれども。
なんかよくわからんことになっててな。「wsl.exe」が「見えない」んだわ。なぜか MSYS からだけ。cmd.exe から where しても、PowerShell から Get-Command しても確かに実体が「c:/Windows/System32/wsl.exe」であることがわかるの:
1 c:\Users\hhsprings>where wsl
2 c:\Windows\System32\wsl.exe
1 PS c:\Users\hhsprings> Get-Command wsl
2
3 CommandType Name Version Source
4 ----------- ---- ------- ------
5 Application wsl.exe 10.0.19... C:\WINDOWS\system32\wsl.exe
けれども MSYS ネイティブからアクセスしようとするとことごとく不可視なの:
1 [me@host: ~]$ ls -l /c/Windows/System32/notepad.exe
2 -rwxr-xr-x 2 hhsprings Administrators 165888 Dec 7 2019 /c/Windows/System32/notepad.exe
3 [me@host: ~]$ ls -l /c/Windows/System32/wsl.exe
4 ls: /c/Windows/System32/wsl.exe: No such file or directory
msys2 からは可視だった。のでほんとにワタシが持ってるヤツだと MSYS だけなの。ワタシが使っている Python は普段使いは公式 Windows 版 CPython のなので:
1 Python 3.9.10 (tags/v3.9.10:f2f3f53, Jan 17 2022, 15:14:21) [MSC v.1929 64 bit (AMD64)] on win32
2 Type "help", "copyright", "credits" or "license" for more information.
3 >>> import os
4 >>> os.stat("c:/Windows/System32/wsl.exe")
5 os.stat_result(st_mode=33279, st_ino=23362423068537443, st_dev=2114937368, st_nlink=2, st_uid=0, st_gid=0, st_size=107520, st_atime=1647133964, st_mtime=1646973084, st_ctime=1646973084)
Goからもちゃんと可視だった。うーん。仕方ないので exemimicry で包んじゃおうと。さすれば MSYS からもダイレクトに wsl を叩けるようになる:
1 [me@host: ~]$ wsl --shutdown
2 [me@host: ~]$ # 以下は MSYS ネイティブな stat
3 [me@host: ~]$ stat /c/Windows/System32/notepad.exe
4 File: `/c/Windows/System32/notepad.exe'
5 Size: 165888 Blocks: 162 IO Block: 1024 regular file
6 Device: 6218h/25112d Inode: 1565298 Links: 2
7 Access: (0755/-rwxr-xr-x) Uid: ( 500/ hhsprings) Gid: ( 544/Administrators)
8 Access: 2022-03-12 08:09:08.000000000 +0900
9 Modify: 2019-12-07 04:40:00.000000000 +0900
10 Change: 2019-12-08 00:12:57.000000000 +0900
11 [me@host: ~]$ # 以下は WSL2 の stat
12 [me@host: ~]$ wsl stat /mnt/host/c/Windows/System32/notepad.exe
13 File: /mnt/host/c/Windows/System32/notepad.exe
14 Size: 201728 Blocks: 240 IO Block: 4096 regular file
15 Device: 32h/50d Inode: 4785074605636126 Links: 3
16 Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
17 Access: 2022-03-13 01:20:42.000000000
18 Modify: 2022-03-11 04:32:41.000000000
19 Change: 2022-03-11 17:47:59.000000000
このコマンドライン一行の中に、どれだけアホな無駄フローがあることを懇切丁寧に説明してもいいんだけれど、ご想像にお任せ…かな。頭の体操にいいかもよ。(MSYS 有無によらずもともと複雑なのが、さらに輪をかけてるのよ。)
にしても /mnt の下の見え方が謎なんだよな。ubuntu.exe を介してそちらから覗き込む場合は /mnt/c でホストのドライブにアクセス出来るんだけど、wsl コマンドからだと「/host」という層が見えるの。複雑よのぉ…。
なお、ubuntu.exe (などインストールしたディストリビューション)は不可視なわけではなくて、単にわかりにくい場所にインストールされてる。ワタシの場合は:
1 [me@host: ~]$ c:/Users/hhsprings/AppData/Local/Microsoft/WindowsApps/ub*
2 -rwxr-xr-x 1 hhsprings Administrators 0 Mar 12 21:08 c:/Users/hhsprings/AppData/Local/Microsoft/WindowsApps/ubuntu.exe
MSYS や cygwin/msys2 と WSL/WSL2 を共存させて使うということに、今後も果たして意味を持ち続けるだろうか、というのが今後のテーマかなぁという気がしてる…んだけど、その話は「おいおいで」の中でしたほうがいいな。MSYS には MSYS の価値が今後もあり続けることだけはワタシには自明なんだけどね、でも WSL/WSL2 がその意義を少し薄めることにはなりそうなの。こういう Microsoft 自身による「POSIX or Unix サブシステム on Windows」は、ワタシの知る限り WSL が三代目で、正直初めてちゃんと日常使い向きになりそうな気がしてるのでね。
一代目二代目のうちの一方が SFU だったのは確かなんだけど、もう一つあったんだが、思い出せん…、なんだっけかなぁ…? どっちも「シームレス? ナニソレタベレンノ」がヒドくて、とても日常使い出来るシロモノではなかった。業務でちょっとだけ使ったことはあったんだけれどね。アレを知ってるので、よくぞここまで来た、と思う。(ベーステクノロジとしては VirtualPC, VirtualBox, VMWare などのような仮想化なのだが、ユーザエキスペリエンスとしては、それらよりも「使いやすくなった SFU」に近い。つまり境界をかなり曖昧に考えて使うことが出来る。Docker を介する場合は別だけど。)
惜しむらくは Windows 11 にしないと WSL2 は linux の GUI を使えないてこと。どうしても本物の linux デスクトップしたければ、今は従来通り VirtualBox などを使うのが(Windows 10 では)近道。X サーバだけ動かして Windows ネイティブな X クライアントを…てのが出来るのかどうかは、探ろうともしてない。たぶん無茶だろうから。(かつてはいくつかあった Windows 版 X クライアントが、今でもちゃんと動くものがあるのかすらわからんし。)
2022-03-15 17時追記:
MSYS 云々関係なく、コンソールにも何か影響を与えている模様。
ほんとに WSL が犯人かはまだ断定はできないけれど、コードページ932の日本語が表示出来なくて困っていたら、「プロパティ」のフォントサイズがいつの間にか無効値になってて、フォント指定も空になってた。なんかほかにも色々出てきそうだなぁ…。
2022-06-18追記:
「MSYS だけ特殊」という言い回しは「ワタシが日常使いしているもので言えば」ということを言外に含むわけだが、msys2 もインストール自体はしてて、たまに検証のために動かしたりはする。そして今日「msys2 でも」という厄介ごとを発見した。
wsl の話ではなくて、「wsl に基づいた docker」(つまり Docker Desktop for Windows)の話。msys2 や cygwin にはそれネイティブな docker があると思うけどそれではなくて、非cygwin系な Windows ネイティブな docker、これを msys2 から起動する際の問題。git-bash でも同じことが起こるようだけれど:
1 [me@host: ~]$ # そもそも docker.exe へのパスも通ってないので、なんとか通したとして:
2 [me@host: ~]$ docker run -it --rm -v /f/Videos:/videos hhsprings/ffmpeg-yours bash
3 the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'
存在を知らないと「prefixing」の英語の意味が取れない(ワタシは取れなかった)のだが、これは winpty コマンドに頼りなはれ、と言ってるだけ。msys2 なら pacman でインストール出来る:
1 [me@host: ~]$ pacman -S winpty
2 [me@host: ~]$ winpty docker run -it --rm -v /f/Videos:/videos hhsprings/ffmpeg-yours bash
もとの MSYS と msys2 でどっちがユーザ体験として快適かなんて、比較するのが失礼なくらい自明、msys2 が圧倒的に快適、なのはわかったうえでワタシは msys2 を使ってない。のであまり msys2 に対する「文句」を知らないのよね。けどたまにこうやって使えば、やっぱり何かしらはあるんだよなと。
ちなみに何をしたくて msys2 してみたかというと、これはデバイスマッピングの関係。msys2 からは「/dev/sr0」だのが見えてるんだよね、これを使えないだろうかと。思ったんだけど、これはうまくいってない。ダメな気がする。
