【Bash】Windows Subsystem for Linux【WSL】10

ついに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】9
http://mao.5ch.net/test/read.cgi/linux/1607589861/

自分の名前変更しているので
ディレクトリのところがおかしくなっているのは打ち間違えです

>>200
Windowsはログインじゃなくてログオンっていうんですが
いつからログインシェルっていうようになったんですかー？

ああなるほど、そういう下らんところに突っ込んでたのねw
そりゃスマンな

驚く程しょうもなかった

Microsoft 製のWindows Terminal では、
コマンドプロンプト・Power Shell・WSL Linux の3つを起動できる

他には、VSCode の拡張機能・Remote WSL もある

デスクトップあたりに、プロジェクトディレクトリへのショートカットを作っておいて、
ダブルクリックで起動できる

リンク先
C:\Windows\System32\wsl.exe code .

作業フォルダ
\\wsl$\Ubuntu-18.04\home\ユーザー名\proj01

そういうこと。Windowsにとってシェルはエクスプローラーしかないから
わざわざログインだかログオンだか区別なんかしてないし
ましてやcmdだかpwshだかをログインシェルとか
お前はいつからcmdやpwshでログインしたんだってなるやろ
ちゃんと>>178よめや

> Windowsにログインシェルなんて無い
> ログインシェルと呼べると言えるのはせいぜいエクスプローラーだ
>
> Linuxで言えばデスクトップ環境からターミナルソフトを起動するのと同じ
> pwshかcmdか、そしてbashを起動できるようになった

ホストマシンがWindowsだとして、LinuxをVMで使う場合とWSLで使う場合のメリット・デメリットがよーわからん。
WSLって何が便利なん？

>>208
同じ質問を繰り返すな。わざとか？
答えはすでに出てるぞ。

151 名前：login:Penguin[sage] 投稿日：2021/04/29(木) 01:30:56.14 ID:4qqDAhC8
WSLって仮想マシンとどっちがいいんだろう？

152 名前：login:Penguin[sage] 投稿日：2021/04/29(木) 05:02:19.49 ID:f4S0NYMP [1/3]
仮想マシンにWindowsと連携機能をつけたがWSL2

連携機能が不要って言うなら仮想マシンだけでいいが
連携機能があるからWSL2が人気なんだよ

Server Coreの場合はいわゆるログインシェルはコマンドプロンプトだけどね
WSL入れてみたけどこの場合はいまいち使い道が浮かばないなぁ
ttps://i.imgur.com/aixLIZT.jpg (116kB)

WSLが開発ツールだとしっていれば、サーバーとして使う
Server Coreで使うものじゃないってのは普通にわかると思うけどな
つまりVisual Studioをサーバーで使うかって話だよ

wslg使えばvimでクリップボード共有できる？

>>209
でもWSLでは最新のGUIアプリがろくに動かないんでしょ？
Windowsとの連携って、VMの共有フォルダにデータ置けばいいだけやんけ。

WSLを使うやつは馬鹿ということがよくわかったｗ

>>213
bashでGUIアプリが動かないでしょとか言われても困るんだがｗ
それはbashやターミナルのせいやろ

>>213
え？ Windowsとの連携ってVMの共有フォルダのことだと思ってるの？
ぜんぜん違うんだから、お前の主張は的外れだな

>>215
LinuxでターミナルからGUIアプリの起動できることも知らんのか・・・

>>216
え？
連携ってのはデータを処理する過程において
WindowsとLinuxの両方でするって事でしょ？
ホストOSのデータをゲストOSの共有フォルダにしとけばできるでしょｗ
なぜに不完全なWSL上のLinuxを使うのか意味がわからんｗ

echo $PATH | tr : "\n"
とすると、Linux のパスの後ろに、Windows 側のC ドライブのパスも追加されている

/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

/mnt/c/WINDOWS/system32
/mnt/c/WINDOWS

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

which notepad
ではダメ。.exe を付ける必要がある

notepad.exe .bashrc
で、Windows側のメモ帳で、開ける

つまり、Linux側から、Windows側のアプリを使える！
逆はダメ。Windows側からLinux側をいじれない

両方に、同じアプリを入れなくて良い

which code
/mnt/c/Users/Owner/AppData/Local/Programs/Microsoft VS Code/bin/code

code .
で、VSCode でカレントディレクトリを開ける

>>217
> LinuxでターミナルからGUIアプリの起動できることも知らんのか・・・

な？そういうことやろ？ｗｗｗ
Windowsとの共有っていうのは、ターミナルからGUIアプリの起動ができることなんだよ

すごいやろ？ WSLだとターミナルからexplorer.exeとか実行できるんだ
ものすごーく便利だろ

>>218
> ホストOSのデータをゲストOSの共有フォルダにしとけばできるでしょｗ

共有フォルダにしなくてもできるから連携なんだよｗ

>>220
すまんが、何が便利なのかサッパリわからんｗ
VMでLinux立ち上げといて、explorerなんぞはWindowsから素直に起動すればええやん。
わざわざWSLから起動する意味がサッパリわからんｗｗｗ

>>221
VM上で10秒で設定できることを回避するメリットって
ほとんどないと思うけどｗ

>>222
ターミナルからGUIアプリの起動できることも知らんのか・・・

>>223
> VM上で10秒で設定できることを回避するメリットって

じゃあそのVMのLinuxからexplorer.exeを起動してみてください

WindowsにおけるWSLはLinuxにおけるWineみたいなもんで、
Wineより出来が悪いクズ環境です。

>>225
だからそれをやる意味がないっつのｗ
理解できないのか？
それができて何のメリットがあるんだ？
ホストOSは隣で動いてるのに。

そもそもbashスクリプトの中で「ここはどうしてもWindowsのあのソフトを使いたい」ってケースはないだろ。
そう思うとしたらLinuxを知らないとしかｗ

もし勉強目的ならWSLを使うより5000円くらいで中古ノート買って本物のLinux環境を作ったほうがいいよｗ
WindowsとLinuxのデータの連携ガー、と言うならVMwareやVirtualBox上にLinuxをインストールして、
データの連携はNASを介すかVMの共有フォルダでやればいい。
偽物のLinuxモドキのWSLばっか使ってたらカタワになるぞｗ

例えば、Ruby はLinux で正常に動くから、Windows 側に入れなくてよい。
Ruby をLinux 側へ入れておく

一方、VSCode はWindows側へ入れておいて、
拡張機能・Remote WSL で、Linux側のプロジェクトへアクセスする。
編集でも、vim を使わなくてもよい

または、拡張機能・Remote Container で、Docker Compose でも良い

ブラウザは、Windows側のChrome を使う。
つまり両方に、同じアプリを入れなくてよい

vmだとOSそのものを動かさからオーバーヘッドが大きい
その点chromeOSでLinuxを動かすとき使うlxcはコンテナだかやオーバーヘッド少ないというメリットあるけど
WSLはどうなんだろ？

オーバーヘッド以前にWSLは不完全だし使う意味ない

どうしても、Windows でgrep を使いたいので、WSL が楽

Linux側から、Windows側のフォルダに移動して、grep できる

>>203 > Windowsはログインじゃなくてログオンっていうんですが
>>207 > わざわざログインだかログオンだか区別なんかしてないし
なんで自分で自分をバカって言うんだろうw

そもそもWindowsでもシェルを変えられることも知らんのだろうな
https://docs.microsoft.com/en-us/windows/configuration/kiosk-shelllauncher

>>227
あるよ
カレントディレクトリをExplorerで開きたいときexplorer.exe .ってよくやるよ

>>235
あほやｗ

>>233
探せばgrepのwin移植版があるのにｗ

Linux のアプリをWindows へ持ってきたようなものは、たいてい日本語でバグる。
ファイルシステムも異なるし、外人が、CP 932 を知ってるわけないから

だから開発環境は、絶対にLinux・UTF-8 じゃないとダメ

ほとんどのアプリ・言語がLinux用で、
Windows用に作られているものは、ほとんどない

特に、ウェブ系ではそう

>>231
ChromeOSもVMだよ（VM＋コンテナ）
LXCを動かす為だけの軽量OSをKVMで動かして、その中でLXCを動かしてる
Linux環境で何が起こってもChromeOS側に影響しないように、動作速度よりもセキュリティを重視したためにそうなった

>>237
> 探せばgrepのwin移植版があるのにｗ

「探せば」が答えじゃんｗ
いくつものWindows版を探すのか
Ubuntuのものがすべて使えるのか

WSLは「設定済みのものを用意しておきました。」っていうのがメリットなんだよ。
そして誰もが同じ状態だからvscodeやDocker Desktopみたいに
WSL2前提のツールというものだって作れる

これがオレオレ設定のオレオレ仮想マシンだったら
Dockerはそれに合わせたツールを作ることができない

>>234
Windowsはシェルを変えることを公式サポートしてません
だからシェルというのは唯一のシェルであって
ログオンに使うシェルなんてものをわざわざ設定したりしません。
Linuxはログインシェルはシステムシェルと違うものだって知ってる？
違うから明示的にログインって言わないといけないんだよ

>>241
意味が分からん。
公式にサポートしてないとか関係ないよ。

>>231
WSL2は仮想マシンのUbuntuとかだといろいろ立ち上がるサービスがないから軽い
なんのサービスも実行しないMS独自の軽量のLinuxを起動してる
だから圧倒的に起動速度が速くなってる

WSL2のUbuntuはその軽量Linuxの上でコンテナとして実行してる
同じUbuntuであっても最速で最軽量のUbuntuと言える

>>242
公式にサポートしてない＝シェルを切り替えることはしないから
ログオンシェルなんて言い方をしないんだよ
Windowsの場合は単なるシェルとしか言わない

>>244
それはあなたの思い込み。

wslgっていつ来るかね？

>>245
> それはあなたの思い込み。

そう思うなら、MSの公式ドキュメントでログイン（ログオン）シェルと呼んでるところがあるか？で
決めようじゃないか。俺は探したけど見つからなかった。思い込みじゃないって言うなら
お前は書いてあるところを見つけてこれるんだろう？

システムシェルとか言う謎用語使われてもw

>>247
そもそも
https://docs.microsoft.com/en-us/windows/configuration/kiosk-shelllauncher
は、MSの公式ドキュメントなんだがw

笹島が降臨してこのスレなレベルが一気に上がったな
感謝しかないわ

>>243
Windowsを起動しないと使えないんだから結局遅いんじゃね？
しかもubuntuのサブセットだし。
まだPuppyLinuxの方が速くてちゃんとしてると思うんだが。

>>249
MSのドキュメントで使われてたら正しいとは限らない。
RFCとかの規格を無視して独自用語を使い始めるのは大抵MS。

>>240
>WSL2前提のツール

それ作ったとして何のメリットがあんの？
無意味なことができてもちっとも嬉しくないんだけどｗ

>>251
何言ってんだこの馬鹿

内容のある反論ができなくて馬鹿と罵るだけの初心者君

.bashrcとかスクリプトをWindowsのメモ帳で参照・編集しかも保存までできてこれは便利
仮想マシンにもクリップボード共有とかあるけどさ

>>246
最短でも22H1でない？

>>210
Internetからファイルをダウンロードするとき、wgetとかあると良いなって思った。
wslが使える事は知らなかったから、別のマシンでダウンロードしてコピーしたけど

>>257
それくらいなら、Invoke-WebRequest で

WSL入れるにしても、どの道ディストリビューションのパッケージ(appx)は取ってこなきゃならないので…

grepやらwgetていどならMinGWでいいと思う。

>>247
> そう思うなら、MSの公式ドキュメントでログイン（ログオン）シェルと呼んでるところがあるか？
https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsalogonuser

> 決めようじゃないか。俺は探したけど見つからなかった。
情弱すぎ

で、システムシェルって何？w

>>251
> MSのドキュメントで使われてたら正しいとは限らない。
> RFCとかの規格を無視して独自用語を使い始めるのは大抵MS。
いきなり何を言い出した？
話の流れをちょっとは読んだ方がいいぞ

>>257
Windows 10 / Windows Server 2019 なら curl.exe でいいかと

>>259
MinGW入れるならWSLの方が良いぞ。普通にubuntuとか使える

wgetとcurlは似て非なるツール

>>261
ありがと、知らなかった。
curl.exeはc:\windows\system32に居た。

>>258
Invoke-WebRequest ってServerCoreで使えるのか?

>>263
> wgetとcurlは似て非なるツール
誰も同じツールだなんて言ってないぞw

>>265
PowerShell のコマンドだから使えると思う

WSLで不完全なubuntuモドキを使うくらいならVMで本物のubuntu環境作るわ。

>>262
使い分けてる。
powershellとかcmdも使いたいこともあるし。

>>267
時代遅れ。

そいつは使いどころをわかっていないだけだからｗ

最近VM知ったんじゃね？
そもそもWSL2がVMであることすら知らなさそうだしw

MSYS2 は、日本語などでバグる。
LinuxはUTF-8 だが、Windows は、CP932・UTF-16 などを使っているから

WSL2 は、本物のLinuxだから良い。
しかも、MS のサポートあり

カーネルの更新も、自動的にやってくれる

>>194-195
に書いたように、

Windows 用のyarn をnpm じゃなくて、インストールして、
コマンドプロンプトで、where yarn と実行すると、

C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js

これをWSL 側で、which yarn と実行すると、
/mnt/c/Program Files (x86)/Yarn/bin//yarn

yarn はシェルスクリプトで書かれていて、
その中で、yarn.js が読み込まれるようになっている

つまり、WSLでも動くように作ってある

>>178
今更だけどubuntu on wslのシェルにpwsh使ってるって意味
紛らわしくてごめん
aptから入るし$profileも共有出来て快適

しかしまあ、デフォルトユーザーのままだとbash.exeでpwshが立ち上がるのは変な仕様だね…
デフォルトユーザーはadmin専用にしててbashのままだから気付かなかった

>>206
に書いたように、

MS 製のWindows Terminal を使えばよい。
コマンドプロンプト・Power Shell・WSL Linux の3つを起動できる

他には、VSCode の拡張機能・Remote WSL もある。
vim の代わりに、VSCodeを使うのも良い

普通の仮想マシンは起動と終了が面倒だが
WSLだと一瞬で起動してシャットダウンも不要だから気軽に使える。
bashからwindowsとlinuxのコマンドを混ぜて普通に使えるのも便利。

不便なところはUSBが使えない、外部ネットワークからのアクセスが面倒、Hackを使わないとsystemdが動かずsnapパッケージや一部のコマンドが使えないといった感じ。

あと仮想マシンは固定のメモリを確保してしまうが
WSL2だと動的確保になるのでメモリを無駄に消費しない。
キャッシュがメモリを無駄遣いする事があるが自分は
~/.bashrcに
# キャッシュが1000MBを越えたらクリア
if [ $(free -m|awk '/Mem:/{print $6}') -gt 1000 ]; then
sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
fi
といったものを追加して対処している。

一々、キャッシュを消す必要があるの？
何かでメモリが必要になったら、OS がキャッシュを消すだけでしょ？

自分で消しても、また同じものが先読みされてしまうだけなのでは？

WSL2はHyper-Vアーキテクチャーなのにこの人は何を言ってるんだろう…
https://docs.microsoft.com/ja-jp/windows/wsl/wsl2-faq

>>277
WSL2によるホストのメモリ枯渇を防ぐための暫定対処
https://qiita.com/yoichiwo7/items/e3e13b6fe2f32c4c6120

>>278
WSL2は専用のlinuxカーネル用にカスタマイズされた
軽量VMでHyper-Vをそのまま使ってるわけじゃないぞ

おまえらが使いたいLinuxの機能ってどうせgrepやlsやsortやsed,awkくらいだろ。
あと簡単なbashスクリプト。
そんなレベルならbusybox使えばいいんだよｗ

>>279
ありがとう。今でも、メモリを使い果たすのかな？
下のサイトでは、うまく行ってるみたいだけど

2021/4/27

WSL2 + Docker をメモリを節約しながら使えるか
https://zenn.dev/takajun/articles/4f15d115548899

.wslconfig で、メモリ制限する

>>282
今は最大メモリのデフォルト値が実装メモリの半分
または8GBのうち小さい方が適用されてたはず

漏れは、Ruby on Rails をやるから、

WSL2, Docker Compose, VSCode, Node.js までが初級者の範囲

>>272

Unixで日本語使うのがダメだわなぁ。

>>278
本家の機械訳なんだけど。

bash scriptやらgrep, sed, awk, perl, pythonなどのライトユースなら
WSL1のほうがいいと思うけど、どうなんだろ。

それくらいならgit bashでもよさそう

>>280
誰もそのまま使ってるなんて言ってないよ
アーキテクチャーってわかるかな？w

>>289
何がいいたいの？

>>281
lsですら使えないものをどうしろと

WSL2のLinuxカーネルって、自分でビルドして差し替える事もできるから、そこまで特別なモノでもないようだけど

カーネルファイルがゲストのファイルシステム上に無いってのは、VMとして特殊ではあるかなぁ

>>290
> 普通の仮想マシンは起動と終了が面倒だが
> WSLだと一瞬で起動してシャットダウンも不要だから気軽に使える。
普通の仮想マシンもゲストのシャットダウンなんて不要なことも知らんの？
Hyper-Vなんてホストリブートしてもゲストはそのまま（もちろんホストのリブート中は止まってるけど）稼働してる
WSL2もそれを踏襲してるだけ

>>293
普通の仮想マシンと言うか、普通のLinuxが起動する余計なサービスが不要
あれが起動時に時間がかかってメモリも食う

みなさん、議論の末だんだんWSLが何者であるかがわかってきたようですね
感心感心w

>>294
仮想マシンの話なのなのかゲストOSの話なのかはっきりしてくれ

>>296
実装方法ではなくて、なにを利用者に提供しているかが重要
MSが開発したソフトが素晴らしいという話をしているのであって
自作すればいいという話でもない

>>293
Hyper-Vは使ってなかったしVirtualBoxは以前はぶっこわれてたらしいのが改善されてるのか
しばらく使ってなかったから知らんかったわ

Linuxとの統合を目指すWindows 10
https://news.mynavi.jp/article/20210502-windows10report/

Microsoftの本気度を探ってみたい。先日、日本マイクロソフトの発表会で「WindowsとLinuxの融合を目指しているのか」と尋ねたところ、
日本マイクロソフト Azure ビジネス本部 マーケットデベロップメント部 シニアプロダクトマネージャー/Azure SME 廣瀬一海氏は、個人的見解としながらも、以下のようにコメントした。

「2004年4月にWix(Windows Installer)をオープンソースとしてSourceForge.netにリリースしたことからも分かるように、当初から融合を目指してきたと思う。
　WSLからTensorFlow経由で機械学習し、その結果をgnuplotでグラフ化できる利便性は大きい」

また、日本マイクロソフト Azure ビジネス本部 マーケットデベロップメント部 プロダクトマネージャー/Azure SME 佐藤壮一氏も同じく個人的意見として、
「開発者目線では統合を狙っていると思う。1つのプラットフォームでWindowsとLinuxアプリの実行環境を実現し、統合に向かっている印象を受ける」と回答している。

>>299
WindowsとLinuxの融合というより
WindowsにLinuxを融合させるって感じよね
Linux側はWindowsなんて知ったことじゃないし

> 筆者自身はKDEやGnomeをWindows 10上で使いたいとは思っていないのだが、

誰もそんなもの使いたいと思ってないと思うし
MSが実現しようとしてるのもそれじゃないでしょ？

KDEやGnome（というWindowsよりも劣ってデスクトップ環境）を使いたいなら
それこそ仮想マシンを使えばいい
そんなクソデスクトップ環境なしに、Linux GUIアプリを使えるのがいいんだから

融合
その名称は？
winux？
Lindows？