【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/

>>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だと思いこんでいた。

ZIPの作者はもうお亡くなりに

死因なにかと思ったらアル中かよｗ

そんなことになってるのか
文字コードって複雑怪奇だな

>>964
ふ・・・複雑怪奇だな・・・？

重怪奇分析

>>965
こんなの序の口だ
文字コード問題の本当の恐ろしさはこんなものではない

文字コードの話はスレ違い

>>961
アプリ側の問題なんだから今もクソもない

アプリが決めたファイル名をOSがまともに使えないのが問題なのに、なんでアプリのせいにするんだろう？
頭おかしいな。

アプリが決めたファイル名をOSは正しく扱えるが？

OSが決めたファイル名をアプリが扱えないんだからアプリの問題だって話だろ

Windowsはunicodeを扱うのに独立したワイド文字系のAPIを作っちゃったから
アプリが対応しないといけない
最近はようやくロケールの文字コード自体をUTF-8にする流れになってるようなので
マルチバイト系のAPIのままUnicode対応するのが今後標準になるのかもしれんけど

>>973
根本原因はUnicodeだけどな。
最初にUTF-8というものを作らず16bitにすべてを詰め込もうとした
Windowsはその最初のUnicodeに対応しただけ
16bitのUnicodeはどうやってもAPIを分けないと対応できない

ま、OSがUTF-8になったとしても、アプリが対応してないと結局意味ないんだがな
だから最初からアプリの問題

訂正
× OSがUTF-8になったとしても、
○ Unicode対応でないアプリのロケールを（ShiftJISではなく）UTF-8として扱う

Unicode対応でないアプリのロケールとしてUTF-8が選べるようになったとしても、
ShiftJISを前提にしているアプリが、文字コードが異なるUTF-8対応になるわけじゃない

UNICODEの元になったJ-Starのコード体系
を勉強してから言え

勉強した。で、お前は何が言いたい？

UTF-8と何が違う？

質問に質問で答えるなよ。

まずお前が何を言いたいのかに答えてからだ

むしろunicode対応が早かったがゆえに
unicode側の変更に振り回されてる形

一時期はUTF-8は運が良かったとか思ってたけど、
Unicodeは更に混沌を極めて、UTF-8でも1文字が最大8バイトにまでなってしまって
単純なアルゴリズムで1文字の境界を知ることは不可能になってしまったからな。
どちらにしろ、Unicodeを扱うには専用のライブラリを使うことになる

>>971
何言ってんのこの馬鹿

NTFS上に255バイト以上のファイル名のファイルを作って、WSLから参照するとWSLがコケるな、WSL2でも一緒
制限がバイトと文字の差だと思うが…

LinuxはCIFSでマウントしてもこんななんだろうか？

NTFSは255文字で255バイトを超えるバイト数を扱えるが
ext4は255バイト。Linuxは互換性のため255バイト以内にしておいたほうが良い

sambaでファイルサーバーを作ってるが
時々Windowsの長いファイル名をLinuxで扱えなくて困る

>>980
15万出して、同じ物だと気づかなかったのププー

>>986
なにか面白いことを言い出したなｗ
何が同じものだって？

次スレキボンヌ

【Bash】Windows Subsystem for Linux【WSL】6
https://mao.5ch.net/test/read.cgi/linux/1560665525/

「OSがファイル名を決める」ようだから、ファイル名生成APIをたたけばいいのかな？
それなら字化けは起こらないもんな。
ユーザーが意図した名前で保存できないけど。

FTP鯖をWin側に立ててみたらFTPクライアントから見えるファイル名のコードはSJISだった。
Dirコマンドをリダイレクト保存したらSJISで保存されてた。
まだまだファイル名はSJIS依存からは逃げられそうにないな。

>>990
ファイル名生成APIなんてものはないけど、
そのAPIで絵文字が生成された場合、アプリが対応していなければ文字化けが起こる
文字化けが起こるのはアプリの問題だって話をしてるんだがわかってるか？