【Bash】Windows Subsystem for Linux【WSL】5

Install the Windows Subsystem for Linux
https://docs.microsoft.com/en-us/windows/wsl/install-win10

前スレ
【Bash】Windows Subsystem for Linux【WSL】4
http://mao.5ch.net/test/read.cgi/linux/1541747008/

WSL1ではVMを使ったほうがパフォーマンスが高いから
VMを使ったほうが良いというユーザーが一定数いるけど

WSLの機能しか入ってないinitだからかinittabも見てないっぽいしなぁ
自動起動は.bash_profileからSUID付けたシェルスクリプトでも叩くのがシンプルなのかな

>>864
VMじゃなくて、WindowsにLinuxが統合されたと考えるのが正しいんだよ。

Windows起動 = Linux起動
だから自動起動はWindowsの起動時にWindowsの機能を使って行う。

正直あまりメリットを見いだせないなこれ…
使い勝手はWSLとそう違いがあるわけでないのだけど仮想化するなら意味ない気がする
Docker動くのもHyperV上では既にネイティブとは言えなくなってしまったしssh経由の操作と変わらない
ポータビリティ考慮するならむしろVMの方がいいとすら言える

WSLの目的は利便性だから
どうも実装に目が行ってる人ばかりいるけど、
MacでBSDコマンドが実行できるのと同じ感覚で
WindowsでLinuxコマンドが実行できるという事実が重要

Cygwinとか使ってる人のための機能としては文句なしだろうけど
Linuxの利点殺してるよねこの汎用性のなさは
RDPサーバー目当てで環境変えようと思ったけどLinuxの代替えにはちょっと辛そう

そうか。WSL2では、SSHも利用せずにLinuxの環境にアクセスできるんだな

>>868
Windows側を直接操作できるわけじゃないから全然ちゃうと思う

>>869
macOSの代替って考えたほうが良いよ。
macOSでもX使ってないからね。
X使う人は少数

>>870
ターミナルがWindowsで動くのは大した利点ではないよ
GUIまで統合できるなら話は別だけど

>>856
そりゃそうだけど
ディストリ側が提供してくれんとsystemdに依存してるソフトもあるんだから無いと困るだろ

>>871
Windowsのコマンドを実行できるんだから、
Windowsのコマンドでできることは、WSLからでも実行できるよ

あんたが言ってることは、
「コマンドプロンプトからWindows側を直接操作できるわけじゃない」と
言ってるのとほぼ同義でしょ？

>>874
> ディストリ側が提供してくれんとsystemdに依存してるソフトもあるんだから無いと困るだろ

systemdに依存してるソフトってなに？

WSLならともかくWSL2がmacOSの代替とか片腹痛いわ

>>877
理由を書かないとか、片腹痛いわｗ

WSLもしくはWSL2によって
WindowsがmacOSやLinuxのターミナル相当の機能を実現したってことなんだよね。
GUIに関しては、もとからmacOSやLinux相当のGUI機能を持ってるわけなんだから

足りなかったターミナル相当の機能が強化された

>>875
いや逆ができないでしょ…

>>880
コマンドプロンプトからWSL上のLinuxのコマンドを実行できるし、
WSL上のLinuxからWindows上コマンドを実行できる

Windows 10のコマンドプロンプトからWSL上のLinuxコマンドを呼び出す（バージョン1803対応版）
https://www.atmarkit.co.jp/ait/articles/1805/24/news022.html

Windows 10のLinux互換環境WSLからコマンドプロンプトのプログラムを呼び出す（バージョン1803対応版）
https://www.atmarkit.co.jp/ait/articles/1805/31/news052.html

>>879
GUIを言うならターミナルだけ実現しても意味ないよ
せめてOSXみたいにXぐらい統合しないと
そもそもssh程度で十分なものを実装してもメリットになってないよ

> GUIを言うならターミナルだけ実現しても意味ないよ
> せめてOSXみたいにXぐらい統合しないと

OSXってXと統合されてないぞｗ

>>881
だからこれじゃcygwinと変わらないよ…
何を言ってるんだこの人は

GUIの使用まで考えるなら、対応toolbox入れたVMのほうが描画速いから既存のVMに利点見出す人もいるだろうね
emacs程度の描画なら変わらないけど、vscodeくらいのリッチさだと表示のもたつきがわかっちゃう
hyper-vでもxrdp使うスクリプト提供(元はユーザ作成)してるだけだったし、toolbox相当作ってくれるなんて期待できないか

windows版vscodeのremote-containersがwindows版docker依存なので、WSL2側にdocker入れても
remote-ssh経由して使わないといけないのがとても面倒

>>883
？
OSXのXserverはMacのGUIでX操作できるよ

WSL2に相当に期待してるのはわかったけども
普段Unix環境使ってる人からすると常用はちょっと無理じゃないかな
少なくともDocker以外はMacのがまだマシに見えるし

Dockerについてはパフォーマンス見る限りかなり良いみたいだけど
これもLinux実装を仮想化して動かしちゃうのならVMでいいんじゃないかなって感じ

>>884
> だからこれじゃcygwinと変わらないよ…

cygwinを不要にするためのWSLが作られたのに
cygwinと変わらないと言われても困るんだが（笑）

cygwinはLinuxじゃないので、Linuxのバイナリがそのまま動くことはない
OS付属ですら無い。Windowsが公式にcygwin相当の機能を
独自ディストリやcygwin専用バイナリを使うことなく、
本物のLinuxディストリを使えるようにするために作りました！って最初から公言してる

お前が勘違いしたんやろ？

>>888
いやどう見てもそっちが勘違いしてるんだけど…
コマンドの利便性の話だし

>>886
用語滅茶苦茶で言いたいことがさっぱりわからんが

WindowsのXserver（VcXsrv）はWindowsのGUIでWSLのXクライアントをX操作できるよ
って言えば良いんか？

>>889

MS「cygwinと同じことをWindows標準で本物のLinuxを使ってできるようにしました！」
お前「cygwinと同じことしか出来ないやん」

ってことだろ？

お前「スーパーファミコンと同じことできるものを作りました！」っていうニュースを聞いて
「スーパーファミコンと同じことしか出来ないやん」って思うのか？

普段Cygwin使ってないとわからないのかもしれないけど
fs構造がLinuxと分かれててWindows側の直接操作は難しいし
この時点でLinuxのWineと同じ問題を孕んでるんだよね
元がUnixなら同一環境なのでそもそもこの手の問題はない

そらまあまだ出たばかりだからこれから改善はするかも知れないけどね
現時点ではちょっとな

>>892
両方共UNCパスでアクセスすりゃいいやん？

WindowsのバッチファイルからUNCでWSL上のファイルを参照できるし、
WSLからもdrvfsでWindows上のファイルにアクセスできるやろ？

これはVMでは出来なかったこと

>>890
VcXsrvですら細かい操作に対応がないので
Java経由で死ぬ事があったり

>>891
いやコマンドの利便性の話でしょ？
論点すり替わってるよ君

>>892
うん、だからWineもUnixのPath使ってろって言ってるのと一緒だから
いくら統一してもプラットフォームの違いで固定パスの扱いそのものに
互換性の問題出るって話だよ

>>895は>>893宛ね

そういや1903にしてから試してなかったけど、

エクスプローラで \\wsl$\Ubuntu-18.04\home 以下や
dir コマンドで \\wsl$\Ubuntu-18.04\home とか普通に見れてるな
ファイルも開ける

>>895
シンボリックリンクで解決できる程度の話を問題視してるってこと？

>>894
コマンドの利便性の話だからGUIが云々って話はスレ違い
いい加減やめとけよ。MSは最初からWSLはGUIに対応するために作ってませんって言ってるんだから

>>895
いやWindowsの特殊パスと文字コードとケースの話だけど

>>899
つまりコマンドはまだ不便だってことだね

>>900
バッチファイルからアクセスするときのパスと
WSLからアクセスするときのパスを
共通化してほしいってだけ？

またズレたけど>>898と>>899宛ね

GUI云々はそもそもターミナルの話の派生だから元から関係ないよ
ただMSがターゲットにしてないから別件な！ってそんな子供みたいな詭弁はちょっとどうかと思うよ
ユーザーにはそんなの関係ないんだから

>>902
だからお前は、
「スーパーファミコンと同じことをできるものを作りました！」っていうニュースを聞いて
「ユーザーには関係ない。プレステがしたいんや！」って言ってるのと同じって言ってるんだが。

>>901
影響するのバッチだけじゃなくて全般だよ
「〜ってだけ？」と簡単に言ってるけどOSの根幹の話で根深いからねこれ

>>903
ごめん何が言いたいのかわからない
コマンドの範囲が増えたって言ってもカーネルに近いほど動かなくなるわけだし
取り繕っても他のUnix統合できる環境と比べて別に便利というわけではないよね
Cygwin普通にうんこだし

>>904
根本的に勘違いしてないか？

WSL自体は単一のLinuxカーネルの機能であって、
ディレクトリ構造っていうのはWSLに含まれてない。

WSLっていうのは複数のディストリを入れられる。
そしてディレクトリ構造はディストリによって決めれている。
つまり、Ubuntuの/etcとDebianの/etcのパスは違うものでなければならない
Linuxで同じことをやるならばコンテナを使った状態

Linuxを使ったとしてもコンテナの外とコンテナの中のパスは
それぞれ独立しており、共通化することは出来ないんだよ

>>905
> コマンドの範囲が増えたって言ってもカーネルに近いほど動かなくなるわけだし

自分で答え言ってしまってるやんｗ
「カーネルに遠いほど動くって」

多くのコマンドはカーネルから遠いんだから動く
動くんだから便利だろ。

レスを追っても何がいいたいのかわからないな
そもそも自分はコマンドの利便性が同じでUnixネイティブと比べて不便だろと言ってるだけで
機能がCygwinと同じなんてそんな酷いこと言ってないんだけど

Cygwin(うんこ)と同等の事ができるって言ってるだけじゃん！だからどうした！
ってそれつまり不便と認めてるってことだよね？
それならもうそれで話終わりだぞ？同意してるんだから

>>908
> レスを追っても何がいいたいのかわからないな
> そもそも自分はコマンドの利便性が同じでUnixネイティブと比べて不便だろと言ってるだけで

その不便っていうのが、不便っていうだけで、何が不便なのか書いてないから
何が言いたいのかわからないんだよ

パスの変換にwslpathコマンドを使わないのが行けないのが不便ってことなのか？
コマンドの実行にwslをつけないといけないのが不便ってことなのか？

これらが必要なのはWindowsとWSLをまたがるときだけで、
Windows内、もしくはWSL内にとどまってる場合には必要ないんだから
俺は、そんだけ（またがるときだけ）だろと思うだけなんだが？

不便不便言うばかりで、不便の度合いがさっぱりわからない。

>>906-907
また論点ずれてるよ
少なくともコマンドの利便性云々については
自分も中身で反論しちゃってるんだし、今更目的が違うから云々なんて回避は通用しないんじゃない？
結論出したくないのはわかるけど

>>909
まあそれ全部不便だねうん
比較対象は別のUnix環境だから

>>908
> Cygwin(うんこ)と同等の事ができるって言ってるだけじゃん！だからどうした！
cygwinとの違いを言えばいいの？

- Linuxバイナリをそのまま動かすことができる
- cygwinは独自パッケージリポジトリなので、用意されてるパッケージが少ない。例えばtigコマンドがない
- cygwinは遅い。WSLの方が速い
- cygwinはMS公式サポートではない。
- cygwinはパッケージマネージャーがGUIベース
- cygwinはUbuntuでもDebianでもない
- cygwinはビルドする時のソースコードが違う。ビルドできるとは限らない。
- cygwinは互換性が低い。

>>910
> また論点ずれてるよ
だからお前の論点をはっきりさせろって
お前が論点を言わないのに、論点を合わせられるわけ無いだろｗ

>>864
タスクスケジューラーやスタートアップフォルダにショートカット入れて
PC起動時に適当なシェルスクリプトを実行するように設定しとけばいいのでは
wsl.exe -u root /etc/hoge.sh

>>911
> 比較対象は別のUnix環境だから

つまりスーパーファミコンを作りましたと言ってるのに
お前はプレステと比較してるってこと？ｗ

あぼーんだらけだわ

>>912
出してる例(スーファミ云々)がそもそも君自分で相当に馬鹿にしてるよって話
例えもまともにできてないよ

スーファミと同じものを云々って、こっちはそんな事は言っていない

>>913
もう不毛すぎるからやめるけども、まずこのレスツリーの最初のレス読もう
コマンドの2環境間の使用の話で、そちらはMacでBSD環境のコマンド使うのと同じ感覚でと言ってるよね
コマンドラインでもシェルでも何でもそのまま呼び出せないという点だけでももう感覚違うよね
取り回しにいちいちcygpathやwine挟むのと一緒だから

>>915
その例え好きみたいだけど、もしかして上手いと思ってる　？
最初に言い出してるの君の時点で相当に墓穴掘ってると思うけど

自分から比較して人のせいにし
自分で反論しておいてそれに反論されたら目的が違うとか無茶な回避し

不毛と思わない？
論点ずらしながら中身のない煽り合いでもしたいの？

ごめん>>919のレスなしで
謝ります

伸びてると思ったら、なんだこれ
2人で無駄にやり合うなや…

FUSEでマウントしたディレクトリをUNCパスでWindowsから参照出来るのかとやってみたが、
中身は空っぽだった。
FUSE自体は出来たがちょっと残念。

WSL1ではディストリはカーネルにタッチできずMSから提供されたモジュールやドライバを組み込むだけしかできず
ユーザーもWSL環境はLinuxカーネル上で動作しておらず互換性も限定的だった事を意識して利用する必要があったが
WSL2ではディストリ側でカーネルソースやバイナリまでビルドして提供できるようになり
ユーザーもWSL2上ではホスト環境のWindowsとの親和性が増したVMを貫通したサポートドライバがあらかじめ組み込まれたLinuxディストリをVM上で実行しているという認識で利用できるので
仮にパフォーマンスが変わらないならディストリ/ユーザー双方にとって望ましいのはWSL2の実装だろう

何をギャーギャー喚いているのか知らんけど、マカーが不安症候群起こしてて酷いな
まあGNUユーザランドが広大な実行プラットフォーム得、それらがより安定しパフォーマンスを増してゆくことに、悪魔崇拝者どもが脅威と不安を覚えるのは無理もないか

発狂してるのはmac板荒らしてるエロ同人違法DL無職おじさんですよね

なんだ、またマカーがWSLに嫉妬していたのか

>>917
> コマンドラインでもシェルでも何でもそのまま呼び出せないという点だけでももう感覚違うよね

bashを起動すれば、BSD環境のコマンド使うのと全く同じだよ
Windows上のパスが違うけど、WSL環境だけでやればいいだけだし。
WSL環境の外に出る必要はもうなくなった。

有識者の人に質問。wsl２ってツインムスタングみいなイメージで正解？

>>850
MSが公開してるソース(https://thirdpartysource.microsoft.com/download/Windows%20Subsystem%20for%20Linux%20v2/May%202019/WSLv2-Linux-Kernel-master.zip)から適当にモジュール作って読み込ませることはできるんだけど
zfsonlinuxはコンパイルが通らねえな

まだ、WSL2からWindowsのホスト環境(WSL1でいうlocalhost)にアクセスできないみたいだな・・・
Win側にXサーバー立ててXアプリ動かそうとしたけど、Xサーバーが見つからないから起動しない。

>929
IPアドレスが別になってるだけだろ？
そのことはすでに告知済み。現時点での制限としてよく知られている。

ポートフォワーディングで対応可能なんだから
そのうち対応するだろう

vncとかで乗り込めば良いんじゃないの？

>>929
ちゃんとXサーバーをlocalhost以外からも接続受けるようにしろよ

>>928
zfs 0.7.13はビルド出来てカーネルモジュールのロードも出来たけど、zpool createコマンドでそんなプールは無いって言われた

zfsの使い方を知らないせいだと思うけど…

ネットワークとか、ファイル共有とかはいらなくて
Linuxのソフトを動かしたいだけの人には
WSL1 + X server
のほうがいいってことですかね。

CheckNetIsolation LoopbackExempt
でループバックを許可したら出来ないのかな。

皆WSL2に興味深々だけど、1903から追加されたimportコマンドで、
外部ツール使わずにCドライブ以外にWSL環境作れるようになってるんだな

WSL1とWSL2のexportって何か違うんだろうか

>>931
そうか！
Windowsだしxrdpでもいけるかもしれないな・・・

xrdpでLXDEのデスクトップは表示できたけど、dbusとか依存サービスがもろもろ動いてないので使い物にならず。
WSL2でGUIは無理か、WSL1でも無理矢理やってる感じだが・・・

Cygwin/MSYS2 は、sjis の日本語に対応してないから、日本語でバグル！
Linux のUTF-8 を、Windows でコンパイルしただけ。
sjis など、MS が使っている、文字コードには対応していない！

WSL は、Windows10 が、環境が切り替わる所で、
sjis/UTF-8 を変換いているから、バグらない

sjis などの何百もある、国ごとに異なる、Windows専用の文字コードは、MSしか対応できない。
これらは、その国だけで使われている、国際化してない文字コード！

一方、UTF-8は、全世界で共通の文字コード

とにかく、sjis/UTF-8の変換は、MS以外ではできない。
オープンソースで出来るのは、Ruby も使っている、NKF だけ！

WSL2でDocker動かした人いる？

MS以外ではできないつったりnkfもできるっつたり忙しい奴だな

JA16SJISTILDE

Windows が採用しているのは、sjis を拡張した、CP932。
こういう文字コードを知っている外人は、まずいない

Windows には、同様な外国の文字コードも、わんさかあるけど、
それを使う国の人しか知らない

オープンソースでは、Ruby も使っている、NKF があるけど、
これも、sjis なのか、CP932 にも対応しているのか、よくわからない

だから、UTF-8 以外は、世界中で通用しない！
世界共通ではない！

nkf だけでないと思うが、iconv cp932
があつかえる。

https://www.tcom242242.site/entry/2015/09/05/193816

ほかにもicu でもあつかえる。

ベンチマーク見た感じだとWSL2はストレージのアクセスが頻繁な処理では劇的に高速化しているな
でもメモリアクセスが重い処理では逆に遅くなっている

WSL2にDocker CE入れたら本当に動いたな。
まあ、これから色々見るつもり・・・

https://docs.docker.com/install/linux/docker-ce/ubuntu/

>>939, >>943
何言ってんのかよくわかんないけど、
Cygwinは2009年のver1.7.1以降、デフォルトロケールがUTF-8になってる。
Windowsのファイル名はCP932だけど、Cygwinが変換してくれるので、Cygwin上のプログラムからはUTF-8に見える。

> Windowsのファイル名はCP932だけど
Windowsのファイル名はNT3.1のころからUnicode（UTF-16）
わかってんだろ？嘘つくなよ

メモ帳はとっくにUTF-8標準、改行コードもLFサポートしてるのを知らないジジイだろw

>>948
OSの内部表現じゃなくて、アプリケーションからどう見えるかの話をしてるんだが。
Cygwinの話をしていることからわからなかったか？

>>950
アプリケーションからもUTF-16LEに見えるんだが

アプリケーションからCP932に見えたら
CP932にない絵文字が正しく表示できるわけ無いだろ
リアル馬鹿だなｗ

XPの時に、ファイル名にSJISにできない文字が含まれるとファイル名が壊れるって現象にぶち当たった覚えあるけど今は大丈夫なのか？

NT3.1のときからそんな現象はない

絵文字などCP932では表示不可能なファイル名が正しく表示できるってことは、
表示されるまでのいかなる部分でもCP932が使われてないってことを意味している。
Windowsの基本機能のいかなる部分でもCP932が使われていないという証拠である。

>>953
わからんけどそれはアプリ側の問題じゃないの？

うーむ…
ttps://i.imgur.com/KCirJ9N.jpg

MSのパッチの部分があるみたいだけど、どこを移植すればいいのか良く分からん
(5.2は起動しなかったので差分を調査中)

NTFSじゃなくてFATでもファイル名がUTF-16なのか？

>>958
LinuxでもFAT使えるんだが、Linuxだと何だと思う？

>>953
アプリケーション側が9xとの互換用の古いA系のAPIを使っていると、UTF-16がCP932とか(ロケール設定による)に変換されてアプリケーションに渡るから壊れることがある
今普通にVSとかでコンパイルすると、UTF-16用のW系のAPIが使われるから壊れない
また、今はA系APIをUTF-8用にも使えるようになった

>>958
いわゆる8+3の古いFATでは国ごとに違うコードだったからCP932だったが、Win95以降のLFNではUTF-16

>>960
なるほど、XPの時に起こったのはアプリが95互換機能つかってたからなのか。
今は大丈夫なのね。

>>951
>>952
>>955
自分が間違っていたので、訂正してお詫びする。申し訳ない。
Windows10上でファイル名を絵文字にできることを確認した。

言い訳になるが、Windowsで圧縮したZipファイル内のファイル名は今もCP932なんだだ。
（それをLinuxで展開するときは、CP932を指定しないと、ファイル名のマルチバイト文字が化けてしまう）
おかげで今もWindowsのファイル名はCP932だと思いこんでいた。