【Bash】Windows Subsystem for Linux【WSL】9

ついにWSL2が登場したぜー。こりゃ完全にLinuxだ。ヒャッハー！WSL最高！開発にLinuxは使わねぇー。Windowsで開発してLinuxは動かすだけや！

WSL2アーキテクチャ
https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html

WSL 2では、仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。
このため、コマンドプロンプトなどからwsl.exeなどを使ってbashコマンドを処理する時間は、
現在のWSL 1とほとんど変わらない。また、本物のLinux実行環境であるため、
これまで正しく動作できなかったアプリケーション、例えばコンテナシステム（Dockerなど）や
ユーザーファイルシステム（FUSEなど）も動作させることができる。その上で、現在のWSL 1と同等の機能と使い勝手を実現するという。

WSL 2はWSL 1を置き換えずに併存する
　WSL 2が登場したからといって、WSL 1は廃止になるわけではなく、引き続き利用可能である。

ファイル共有プロトコル「9P」でWSL 1との互換性を確保
　このように、WSL 2とWin32環境の間のファイル共有は、どちらも9Pを使うことになる。
　また、WSLからWin32プログラムを起動する「Win32相互運用性」では、最初にWSL側で、
実行ファイルを判別する必要がある。具体的には、実行ファイル先頭のマジックナンバー
（Win32ではMZ）を見て、LinuxのELF64か、Win32の実行ファイルなのかを判断する。

前スレ
【Bash】Windows Subsystem for Linux【WSL】8
https://mao.5ch.net/test/read.cgi/linux/1590742701/

>>667
日本がGAFAに勝てないのは、未来を見据えたIT戦略を取れないからだろうな
理屈の上ではわかってるでしょ？
そういうMS前提のシステムじゃなくて、ネット前提（リモートワーク前提）で
どんなコンピュータ、どんな場所からでも仕事できるような仕組みにしなきゃいけないことなんて

>>668
社員の30%は大企業勤め
それに入れてないなら御愁傷様w

>>669
IT会社ならまだわかるけど普通の会社にとってITは単なるツールだから管理が容易でコストが安い奴が選ばれるのは当然の帰結
リモートワークでAD対応の製品も多数あるし

>>670
大企業努めかどうかの話はしてない
それが一般的かどうかの話をしてる

所詮お前は大企業のことしか知らない
胃の中のわかずってことだ

あと大企業勤めなんて30%もいないｗ
夢見るのやめとけ

>>651
俺の発言が物議を醸しているが、普通というのは普通の会社って意味で行ったのではなく、ADでクライアントPCが管理されているのが普通と思って発言した。でもそうでもないんだね。俺の発言については他意はないから気にせんでくれ。

wsl2からwindowsのプログラムを実行する方法を教えてください
昔、何も設定しなくても環境変数PATHが通ってて、windowsのプログラムを実行できた記憶があります

>>671
> 大企業努めかどうかの話はしてない
> それが一般的かどうかの話をしてる
30%はそれなりのシェアだと思うけど？

> あと大企業勤めなんて30%もいないｗ
まあ確かに29.9%しかいないよな
http://jobgood.jp/wp-content/uploads/2016/08/619.jpg
http://jobgood.jp/chusho

> 夢見るのやめとけ
現実見せられて悲しいねw

>>673
Linux からの Windows ツールの実行
https://docs.microsoft.com/ja-jp/windows/wsl/interop#run-windows-tools-from-linux

>>674
おや？ わずか30%で世間を知った気になってるのかね？ｗ

>>676
まあ零細とか知ったこっちゃないから
ゴメンねw

>>653
emacs って開発終わってるよね？
俺もemacsの中に住んでるけどw

>>678
emacs からの引っ越し先が見つからん。

>>678
終わってないよ

>>679
VSCodeが有力候補なんだろうけど、オレは移行できそうもない。Emacsキーバインドにしてもダメそう。

windowsでもxyzzy をUSBメモリに
入れて持ち歩いてる。

WSLがemacsと相性が良いって
どんな所がですか？

MacからWSLに移行したんだけどCtrlとCmdがCtrlに統合されたの地味に痛い

Vscodeにvimのプラグイン入れてるんだけどコピペやらなんやら競合しまくってイライラする
ここだけはMacが羨ましいとおもった

>>683
Emacsキーバインドで良ければ、左右のCtrlキーを使い分ける方法がある

>>682
EmacsにはMagic File Namesという機能がある。これをうまく設定すると、
wslpathを使わなくてもWindowsのパスをWSLのパスに変換することが可能となる。
これでWSL上でWindowsのパスを利用できるようになる。emacsclientでWindows
のパスも使えるようになる。
また、wslstartというコマンドをDiredと組み合わせて利用するようにすると、
Diredで開いているディレクトリをExplorerで開いたり、Windowsのアプリの
ドキュメントをDiredから開けるようになったりする。
Diredはwdiredを使うと左右に開いているDiredのバッファ間でファイルの移動や
コピーを簡単にできるようになるので、Explorerの代わりにファイル操作も可能
となる。
WindowsショートカットファイルもDiredで作成、参照できるようにすることが
できるので、Windowsショートカットファイルをシンボリックリンクの代わりに
使えるようになる。

まだあると思うけど、これだけでも随分便利になるかな。

winのpathを足すお節介は切った方がいいと思うぞ、スペースやらの扱いが苦手なので
おれはinuxシェルをpwshにしてるけど、ソフト側での取り扱いの問題は避けられない
数Gbも占めてるx関連全てアンインストールして画像pdfビューアブラウザexplorerだけ/mnt/c/bin作っといてリンク貼ってwsl側のパスに入れた
xなんて要らんかったんや！

>>677
Googleがいつから零細になったんだろう？？？

>>687
どこからそんなアホな結論出てきたんだ？w

>>685
おおお
どうもありがとう！！

>>673
echo $PATH | tr : "\n"
と入力すると、Linux 側のパスの後に、/mnt/c/〜 とWindows 側のパスが続く

which notepad.exe
/mnt/c/WINDOWS/system32/notepad.exe

which notepad じゃダメ。
.exe の拡張子まで付けること

which where.exe
/mnt/c/WINDOWS/system32/where.exe

Windows 側のコマンドを呼ぶ

where.exe notepad
C:\Windows\System32\notepad.exe
C:\Windows\notepad.exe

これも、where notepad じゃダメ。
.exe の拡張子まで付けること

>>682
wslとemacsについては、win側のファイルとの連携の話がでているけど、まずはemacsとしてちゃんと使えるってのが大きいとおもう

emacsは、本体もパッケージも外部のコマンドと連携して動作するようになっている機能が多い。要するに、unixのコマンドを含めたシステムになっているということ。
win版emacsもあるけど、外部のコマンドまでは用意できないし、使えるとしても、パスかうまくあつかえなかったりなど不具合だらけ。パッケージについても同様

自分として致命的だったのはmagitが使いにくかったこと
動作が遅くて、一部の機能は動かなかった

wslで動かせばまさに(ほぼ)フルスペックのemacsが使えるということ

ずっとイキってlinux使ってたけどやっぱwindows/wsl最強だわ
グラフィックをクソの塊のXに投げなくて良いのと、ホストゲストどちらでもシームレスにPowerShell使えるし学習コストも低い

いわゆるLAMP系の開発で統合環境にVisualStudio使ってるなら、WSLは神としか思えないよなあ…

純WindowsでちょっとPerl/Pythonでその辺回ってデータ漁ってマイニングする程度でも
今さら秀丸でやるのもつらいしVSでいいし、なら実行環境はWSL上のLinuxで良くね？ってなる

>>693
VS？ VSCodeでなく？

>>694
VSCodeだけじゃなくてVSも。

それは、私がだいぶ前にVSでの使い方を紹介したのを誤解して受け止めているのでは？
WSL推しだからWSLを使っていると思いこまないほうが良いです。

WSLを普段使いしている身からすると、推してる人の言ってることが大分おかしい。
おそらくこの人、WSLを使ったことが無いです。

Visual Studio でターゲットの Linux システムに接続する
https://docs.microsoft.com/ja-jp/cpp/linux/connect-to-your-remote-linux-computer
Visual Studio 2019、WSLに対応
https://news.mynavi.jp/article/20190508-820095/

>>697
ええ、それが私の使い方です。
その記事にリンクした時点で、使っていないことが推測できます。

なぜだかわかりますか？
使っていればわかるし、使っていなければわからないでしょう。
わからなければ、ズバリと答えることが出来ないでしょう。

↓ずばりと言ってみましょう。

逆に、なぜ私がVSからWSLを使うかわかりますか？
あなたも使っているならわかるはずです。
動機は一つしかないからです。

使っていないなら答えられないでしょう。

↓はいズバッと言ってみましょう。

皆さん良いですか？
この方は、VSからLAMP開発するのにWSLが良いと言っています。

実際に使っている人には、この方の嘘が見抜けます。
この方は、WSLを使えていません。

使ってない奴が使ってる人に向かって「使ってない」と言う滑稽さ。

私はいまもまさにそのような使い方をしていて、テストの合間にカキコしています。
https://imgur.com/qO14BJv

ですからWSLの状態についてよく知っていて、この方の嘘はよくわかります。

使っていると言い張るなら、 >>697 の問題点の一つでも書き込んでみては？

問題は一つも抱えて無いでしょう？
使っていないんだから。笑

ID:ikHpu1qJ はなんでいきなりキレてるんだ？

WSLを推してる人がWSLを使ったことが無いという。笑

使ったことがある人は皆、無暗にお勧めできないと言っています。笑
私も無暗にお勧めできません。笑

> 使ったことがある人は皆、無暗にお勧めできないと言っています。笑

皆ってだれ？

どうせお前等は全員嘘付きだw

使っていない人がWSLをお勧めする理由は、荒らしたいからです。笑

だから皆ってだれ？よ？嘘だったの？

俺は純粋に遊びで使ってるんだが悪いんけ？
pulseaudio鳴らしたり、X使うのにTCP使うのとかおもしれーとか思いながらいじってるよ。
完全な仮想環境じゃ、最近は、何にもしないでも簡単に動きすぎて面白くない。

皆ってだれ？って聞いた途端黙っちゃったｗ

Windows用のadbでlogcat取りながらgrepを使いたい人だっているよ

>>711
無能

皆ってｗ小学生が割りと使う言葉だね

いや、小学生ではないと思う。
WSL推してる子は中学生くらいの子だ。
冬休み中、WSLに取り組んでいるのだろう。

つまりWSLは中学生でも気軽に使える出来栄えって事か
素のLinuxだったら大人でもインストールだけで大仕事なのに

まだ使えていないんだろ。

言ってることがおかしいし。

いやGentooでもなければWSL使いこなすより、素のディストリ使う方が簡単だろう。

「使ったことがある人は皆、無暗にお勧めできないと言っています」
↓
皆ってだれ？
↓
「WSL推してる子は中学生くらいの子だ。」
↓
だから、皆ってだれ？

そこで争うつもりはないけど、wslってLinux環境を手に入れる一番簡単な方法だとおもうんだけど。
有効にしてストアからインストールするだけでしょ

実機のほうが簡単では？

荒らしてる子達は、もともと実機より簡単と言っていた。
俺がマックから開発者を取り戻す意図でWSLを作ったんだろうと説明してから、その路線に変わったんだよ。

まるっきり何もわかっていないようだし、WSL推してるふりして荒らしてる子は、WSLを全く使ったことが無いと思う。

すでにそこにある実機なら簡単だけど、1から作るのは面倒だよ

シリコン錬成術が必要なのか。

>>721
実機だとインストールに時間がかかる
特にWindowsとファイル共有しようとなると
sambaの設定まで絡んでくる

そうやって頑張って設定しても、それは自分だけの設定になるから
既存のツールが、自分の環境を考慮してくれない
つまりwslpathやらdockerのような、公式に対応しているツールが登場しない

>>722
> 俺がマックから開発者を取り戻す意図でWSLを作ったんだろうと説明してから、
それを言ったのは俺。そもそもMicrosoftがそういう意図で作ってる
最初からGUIは対応してません、開発用ですって公式発表してる

>>724
Cygwinの代わりに使う程度なら良いんだけどね。
実機の代わりは無理だろ。

Microsoftは風呂敷を広げ過ぎて失敗することが多いんだよね。
失敗してWSL自体が無くなるより、ミニマムで細々と続いてもらう方がありがたい。

>>727
恥ずかしくないのかｗ

実機Linux使えばいいのに、なぜmacOSを使っているかと言うとその方が便利だから
たとえmacOSの標準コマンドがBSD系でLinuxとは違ってもそれでもmacOSを選んでいた
macOSでも仮想マシンでLinuxを使えるわけだが、わざわざ仮想マシンは使っていなかった

多くのCLIツールが動作するという点だけを見ればLinuxでも同じだが
それでもmacOSを使うのは、やはりGUIが強いからだろう
GUIが強いという点を見ればWindowsも十分なんだがCLIツールが不足していた

そこにWSLが登場した。GUIが強い＋Linuxと全く同じコマンドが使える
これはBSD系コマンドが標準で、OS非公式のパッケージをインストールしないといけない
macOSよりも優れている点。WSLの登場でソフトウェアの開発はmacOSよりもWindowsの方が便利になった

>>728
> 実機の代わりは無理だろ。

やっぱり実機の代わりとして使おうとしてるのはお前のようだな
Microsoftがそういう使い方をするものじゃないと言ってるのにな

なんの話してんだ？

いまWSLで開発楽々なら、開発に使うものと言えば良いんだけど、楽々じゃないからな。
よけいな問題を引っ張り込むだけだろ。

MicrosoftはMacから開発者を取り戻したいけど、WSLはその地点まで行けていない。

>>697 の記事の頃、VSはrsyncとSSHでWSL上のLinuxを操作していた。
ビルドが上がるたびにrsyncが使えたり使えなかったり、たいへん不安定な状態が続いた。
近頃ようやっと直接ファイルシステムを叩くようになって、安定して使えるようになった。

そういうレベルだよ？
こんなもん他人には勧められないわ。

rsyncが安定して使えないから、Microsoftはファイルシステムの相互運用が必須だと考えたんじゃないかな。
代替手段としてSFTPが安定して使えたんだけどね。

さて、それでダメだった理由はなんでしょう？

ウェブ開発者なら問題はもっと深刻じゃないかな。

俺の説明を上辺だけなぞって改変されると、なんか俺が頭の悪い勘違い説明したみたいになる。
ホントやめてほしい。

俺は、Microsoftの意図を説明しただけで、現在使い物になるとは一言も言っていない。
むしろ、自分が日常的に使ってるだけに、まだまだですよと言わざるを得ない。

>>733
> いまWSLで開発楽々なら、開発に使うものと言えば良いんだけど、楽々じゃないからな。

開発でよくある使われ方で「お前が楽々じゃないって思ってるもの」は何？

お前が思ってる「楽々じゃないもの」"以外"は、楽々なんだねって
いうつもりだからよく考えて答えてね。もしくは逃げてもいいけどｗ

>>734
> さて、それでダメだった理由はなんでしょう？

ファイルを重複させて同期するなんて開発する上でありえないし
パーミッションの違いなどを吸収しなければならないので
既存のsambaやSFTPなど使えず、9pプロトコルを新たに搭載するほうが理にかなっているから

>>737
むしろWSLで何が楽々になるんだよ？
実機のほうが楽々だろ。

>>738
ま、使ったことないから、なにも困っていなかったんでしょうな。
使っている人にとっては、とても困ることが在ったんですよ。

>>739
> むしろWSLで何が楽々になるんだよ？
Windowsとの相互運用の設定がすでに完了しているから

LinuxとWindowsとの相互運用で、Windowsのファイルシステムにはない
実行権限をどうやって管理するか答えてみ
実際にやった経験があるなら答えられるはず

>>697 のシチュエーションでファイルの属性で困ることはない。
なぜでしょう？

WSLをお勧めしてる子は、WSLを使ったことが無い。

使ってれば他人にはお勧めできない。

「>>697 のシチュエーションに限り」でファイルの属性で困ることはない。

ということは、

その他のシチュエーションでは困るという意味です。

では、なにに困っていたのかな？
ファイルの属性に困っていたのかな？
ほんとに？
使ってて困ってたの？
そんなわけないなあ。

困ってたのは何かなあ？

とはいえ、WSL有効利用について、俺は結構なノウハウを持っているよ。

WSLはこう使え！みたいな。

>>746
ではそのノウハウの中で、
「世間で一番よく使われると思っている例」を上げてください

Microsoftはウェブ開発者を取り込みたいんだろうけど、まだまだ先は長そうだよね。

今はやめておけ、まだ時期が早い。

>>745
だからどういう設定をするのか聞いてる
実際に使ってれば、実行権限の相互運用をどうするか答えられるはずだが？

ID:ikHpu1qJ って俺の質問に一切答えないよねｗ
やっぱり使ったことないから知らないのかな

>>747
おまえ、俺が言ったことを捻じ曲げて再掲するだろ。
しかも、自分の考えみたいに言うし、
俺は結論を書かずにクエスチョンすることにするよ。
これからは。

>>749
ほんまアホの子やね。
rsyncやSFTPの時代にファイルの属性で困るわけないでしょ。

レンタルサーバーで困ったみたいな話を検索してごっちゃにしてるのかな？かな？

>>752
> rsyncやSFTPの時代にファイルの属性で困るわけないでしょ。

Windowsで編集すると、Windowsには実行属性がないので
それがLinuxに反映されることがない

ということも知らないのかな？やっぱり使ったことなさそうｗ

>>754
それがレンタルサーバーで困った話を検索したと言ってんの。

まあ、Linux板だから、VS使ってる人もWSL使ってる人も少ないだろうけど。
わかってる人が居たら、ちょっと恥ずかしいだろね。
使ったことないんだなってすぐわかるから。

> それがレンタルサーバーで困った話を検索したと言ってんの。

レンタルサーバー（Linuxマシン）で困るなら、
普通のLinuxでも困りますよねｗ

>>756
>>697 を実際にやってみれば良いのでは？

>>697以外の例では困るから
>>697限定にしてるんですよねｗ

exeに実行権限付ければLinux上で起動できると思ってるらしい。

>>759
別の話をするんですか？
それでは、Linuxマシンを使って、Linux上でexeを起動するにはどうしたらいいのでしょう？


念の為、WSLの方が楽々になるという話をしています。

>>739へのレスです
> むしろWSLで何が楽々になるんだよ？

使ったことないのが丸見えだったのだが。
最初からそう言ってるのに。

>>760
まったく別の話じゃないだろ。
やっと気が付いた？
それで恥ずかしくなって誤魔化そうとしてるのかな？かな？

さて、VSは何処でバイナリをこさえるでしょうか？

また質問に答えませんでしたねｗ

つまりWSLの方が楽々なんです。

では、それを踏まえたうえで、なにに困ってたのでしょうか？
そもそもコイツ、Microsoftがなぜ不安定なrsyncにこだわったのかさえ分かっていなさそうだな。
なにに困るのかわからないみたいだし。

>>764
で、半年くらいすると、「実行権限は問題ないと言ったのは俺だ！」と書き込むんだろ？

困っていたといい出したのはお前であって
WSLの方が楽だって言ってるんだが？
話すり替えるなよ

まあ言っときますが、WSLはやめておけ、まだ時期が早い。