【Bash】Windows Subsystem for Linux【WSL】11

ついに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】10
https://mao.5ch.net/test/read.cgi/linux/1615976083/

>>313
へ補足

Docker と、VScode の拡張機能・Remote WSL/Remote Container も使っています

WSL の利点は、同じアプリを、Windows 側/Linux側で、2つ持たなくてもよい。
例えば、yarn は、Windows側だけに入れている

コマンドプロンプトで、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

Linux側で、which yarn
/mnt/c/Program Files (x86)/Yarn/bin//yarn

yarn の内容は、各OS で、3つのパターンで、yarn.js を呼ぶ。
node ではなく、nodejs というコマンド名もあるみたい

1. winpty node "$basedir/yarn.js" "$@"
2. exec node "$basedir/yarn.js" "$@"
3. exec nodejs "$basedir/yarn.js" "$@"

#!/bin/sh
argv0=$(echo "$0" | sed -e 's,\\,/,g')
basedir=$(dirname "$(readlink "$0" || echo "$argv0")")

case "$(uname -s)" in
Darwin) basedir="$( cd "$( dirname "$argv0" )" && pwd )";;
Linux) basedir=$(dirname "$(readlink -f "$0" || echo "$argv0")");;
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac

要するに完成度の違いなんだよな
自分で仮想マシンにLinux入れて頑張ればできる vs 頑張らなくていい
そしてWSLをベースにいろんな技術が作られてるから
WSLに対応していればすぐに使える

>>316
取り敢えず説明等ドキュメントを読んでからにしたほうがいいよ

>>317
読んだ結果なんだが、おまえは自分の意見すら言えないのか？

読んだ上での>>308のレスならヤバすぎｗ

ほらな？自分の意見を言えないんだよ
説得力ゼロな

言う気は無いし説得しようともしていないのだけどｗ

>>313
こんなバッチファイルで行ける。userは変更すること。

set home_dir=user
set src_distro=Ubuntu-18.04
set dst_distro=Ubuntu-20.04

wsl -d %dst_distro% -u root bash -c "mv /home/%home_dir% /home/%home_dir%.orig"
wsl -d %src_distro% -u root bash -c "(cd /home; tar cvf - %home_dir%)" | wsl -d %dst_distro% -u root bash -c "(cd /home; tar xvf -)"

>>318
俺の意見なら俺のレスを辿ればわかるだろ

>>322
間に、コピー用コンテナを置いて、移行できないかな？

Ubuntu 18 → コンテナ → Ubuntu 20

または、データの一部を変える場合は、
Ubuntu 18 → 変換前コンテナ → 変換後コンテナ → Ubuntu 20

>>324
補足

OS が異なるから、コンテナに互換性が無いのか？
それとも、ある程度は使えるのかな？

WSLでMSが手を入れたLinuxモドキを使うくらいなら
VirtualBoxで本物のLinuxをインストールして使った方がいいよね

>>326
それはもう何回も論破されてる
アキラメロン

>>326
ホストOSのパフォーマンス低下が嫌でとかならちょっとわかる

>>328
無理しなくていいよ。
その話題は論破されてる

>>326
目的に合わせて道具を選べない人は論外だよ

メーカーが手を入れたのがモドキなら、この世の大半のLinuxはモドキになるような
WSL2のカーネルもソースは公開されてるからねぇ

initのソースも公開して欲しいね、どんな事やってるのか興味がある

使い分けりゃいいだけという認識だけど、そもそもパフォーマンスには影響ないん？

>>328
ひょっとしてこういう記事に踊らされてない？
ttps://g-geek.net/column/wsl2

>>324
tarボール作ればどうにでもできるのでは？

>>328
パフォーマンスへの影響は当たり前の話で、環境を分けるのが常識なので議論する余地はない

>>322はパイプでtarを流してるから中間ファイルすら作ってない

GPUパススルーは安定してんの？
新しくノート買おうと思ったけど様子見かな

>>299
LinuxからWindowsのコマンドを実行しました。
コマンドで仮想環境を立ち上げて、sshでコマンドを実行するシェルスクリプトです。
仮想環境が立ち上がっていると、立ち上げを無視する様にしてあります。
2回目がそうです。
https://youtu.be/WT9lYVkU8xA

>>338
ではそのやり方を世界中に広めてください。

WSLは「やり方」を統一しているので
WSL用のツールが作れるわけです

WSLは基盤です。エコシステムとも言います

作るものはたくさんあるので言っておきますね。
文字コードの自動変換。
wslpathに相当するパスの変換
ファイル共有の仕組み

ファイル共有の仕組みは仮想イメージをマウントすることで可能。
作る必要はなし。
https://youtu.be/Wd2u0JOB9s8

Windowsから同時に参照できねーだろ
はぁ。使いづら（笑）

WindowsとWSLが同一マシンだって事がわかってないんだよな（笑）
WindowsのVSCodeで編集したものを
すぐさまLinux上から実行できなければ
何の意味もないだろうが

WindowsにはX Window Systemのようにネットワーク上の他のホストにクライアント(アプリ)を表示する機能がないから無理だろう。
マイクロソフトが実装してくれたら出来るよ。
https://youtu.be/meFBmv-jisU

>>343
VMの共有フォルダに有るファイルを編集すればいいだけやんけ
あほなの？

適材適所で使えない人達ｗ

WSLを誹謗する書き込みってやっぱPowerShell信者が書いてるのかな？
WSLの台頭でPowerShell要らない子になりつつあるから

>>344
Remote-Appて違ったっけ

>>343
同期させるか直接編集すれば良いだけなのに何を言っているのやら...

>>348
ゲストOSにsshしX11 Forwardingして、ホストOSのXサーバーに表示しています。
昔のコンピューターは非常に高価だったので、ホストコンピューターにログインして、手元の安価な端末に表示する様に開発された機能です。

>>348
RemoteAppはWindows Serverが無いと使えないが
WSLgはアプリ単位のRDPを使ってる
https://raw.githubusercontent.com/microsoft/wslg/main/docs/WSLg_ArchitectureOverview.png

>>351
いや、Windowsには機能がないというからさ

WindowsのクライアントOSでもRemoteAppは使えるみたいだね
https://i.imgur.com/Zs0pzB2.jpg

WSLgのはFreeRDPがRemoteAppサポートしてて、それを利用してるようだね

>>351

Windows 10 Proなら使えるよ(7の時から)。
レジストリの変更が要るけど。

>>345
パフォーマンスが低すぎる。
パーミッションが保存されない

>>345
> VMの共有フォルダに有るファイルを編集すればいいだけやんけ

今は仮想イメージをマウントするという
間抜けな回答をシたやつを煽ってる最中だｗ
結局共有フォルダを設定しなければいけないし
パフォーマンスやパーミッション問題もあるし
何も問題が解決されていない

341 名前：login:Penguin[sage] 投稿日：2021/12/21(火) 00:47:18.09 ID:JCTchnzy [1/3]
ファイル共有の仕組みは仮想イメージをマウントすることで可能。
作る必要はなし。

>>355
何と比べてパフォーマンスが悪い？

>>351
>>353
xfreerdpを使ってdesktopにWindowsアプリを表示出来ました。
ありがとうございます。
https://youtu.be/oZnJciFNHps

>>356
おまえがマヌケだよ
ろくにVMの知識もないのがバレバレ

>>357
WSL2は仮想マシンを使っている。だからWSL上のファイル操作は速い
その上軽量の9pプロトコルを使って、そのファイルにWindowsから編集できる。だから速い。
その上同じファイルをWSLとWindowsの両方から同時に参照できる

もしWindows上でのパフォーマンスを重視したければ
Windows側にファイルを置いて/mnt以下からアクセスすることもできる
Windows上のコマンドを実行する場合も、ここにあるファイルを実行するだけでいい
WSLからWindowsのパスを知りたい場合のためにwslpathコマンドが用意されている

そういった環境がWSLを入れるだけで完了する。ほぼ全自動でユーザーは何もすることがない。
相互運用性は抜群。誰でもこういう環境として標準化されてるから
たとえばwslpathコマンドを使うシェルスクリプトを、WSL用として不特定の人に配布することもできる

ここまで、お前がやれっていってんの。標準化するのは大変だろうがまあ頑張れｗ

>>360
よくわからんがWSLが出来すぎているということですね。
それは理解できます。

WindowsでもLinuxが使いたい。
そんなワガママを叶えるソフト。

正確にはLinuxコマンドだな
別にLinuxじゃなくてもいい

こういう人は昔からいてmacOSがもてはやされた理由の一つは
Linux（風）のコマンドが使いたいからだし

macOSのコマンドはFreeBSDが由来のものが多いが
別にFreeBSDを使おうと思わないのと一緒

>>363

コマンドって、結局Linuxのことでしょう。
バイナリー互換ってのがみそ。

WSLがmacOSなんかをはるかに凌駕しているところ。

windowsでcygwinじゃなく本物のbash、シェルスクリプトが使えるってめちゃくちゃ便利でうれしいじゃん

ウェブ開発が増えて、開発者がみんなMac使いだしたので、慌ててWSLをリリースしたのではないか。

>>365
bashはLinuxでもgitでもmingwでも
cygwinでもBSDでもbashなんだけどね。
linuxのbashって意味なら正しい。

言いたいことはわかるよ。

>>366
慌てるもなにも、規模が違うし。会社の方針が
クラウド重視になったからでしょ。UNIX互換のsubsystem互換のものは
はるか前から実装されてたし、クラウドで最もつかわれているLinuxに対応
させたというのが普通の考え。
Apple信者の考え方はそうなのかもしれないけど。

>>366
それならmacOS互換のBSDを実装するはずだけどね。
OSが柔軟なので可能だけど、Linux互換にした意味を考えないと。

>>360
仮想マシンを使ってるから速いって・・
アホなのｗ

>>366
それ何年前のネタなんだよｗ

>>372
そのうちM1 macが増えたからWindowsをarmに対応させたとか
言い出しそうだね。

「ARM版Windowsはアリバイみたいに出していただけで、MSが実用に向けてappleの影響」みたいなことにはなりそうだよね
CPUエミュレーションレイヤーも多分Rosettaが先ってことになってる

ARM版Windowsはインテルが「ウチの特許を侵害してる！」って騒いでなかったか？

かつてWindowsはIA-32以外にもAlphaやMIPS、PowerPCでも動いていたわけで

漏れは、grep や、コマンドのパイプで、文字列を変換したいから、WSL を使っている

PowerShell よりも、シェルの方が使いやすい。
Ruby なども使えるし

ほとんどのOSS が、Linux 用だから、Windows では文字化けなどで動かない

素人だけど自分も文字列、テキスト処理は基本中の基本なのでawk,sedも標準で使えるwslは便利

新参で有利なはずのPowerShellが古参bashの引き立て役になってしまってるんだよなあ、現実として

PSはいわばシェル/スクリプト言語界のクリンゴン語だからなぁ

>>380
マジレスするけど、クリンゴン語に対して失礼
PowerShell話者から高度な文明が生まれることはありえない

ウォーフが怒るで

PowerShellはFunctionに外部プロセスの標準出力をパイプで標準入力で受け取るのにかなり苦労する
bashより退化してるのがわかる
マイクロソフトの財力がなければとっくに消えてるシェル言語だと思う

>>383
bashではWindowsのをコトンロールできないから
用途が別と思ったほうがいい。

Unix用として使うことはそれほど重要視してないでしょう。

>>383
例えばbashでWindowsのGUIをコマンドラインで操作できますか？

> Unix用として使うことはそれほど重要視してないでしょう。

Unixだけでなくコマンドプロンプトにも劣るのがPowerShellの現実

>>386
最大の利点はWindowsのすべてを操作をできる事だからね

普通のコマンドラインならCMDでいいんじゃないの？
Unix的な使い方ならWSLのbashでいいんじゃないの？

何が気に入らないんですか？

その論理だとコマンドプロンプトの正当後継シェルはWSLのBashってことになりそうだが

>>388

どっちでもいいんじゃの？

CMDにできてPowershellにできないことより
PowershellにできてCMDにできないこと

のどちらが多いかですよね。

想像するに、PSを使ってないか、これまでの知識でつかえないか、
勉強したけど挫折した人の意見としか思えない。

>>384
PowerShellが他OSに広まらないのは、LinuxやmacOSでWindowsのをコトンロールする需要がないからだろうね

>>389

bashにできてPowershellにできないこと
Powershellにできてbashにできないこと

どちらが多いかも考えてね。
ちなみにbashの知識しかなくてPowershellにできないと思ってる
のは除外ね。

>>390

LinuxやmacでWindowsをコントロールするためにportしたわけではないでしょう。
根本的に誤解してるのかと。

bashと比較して

> ls

なんかunixとちがうなぁ(怒)

> ls -laF
エラー

Powerhsell 使えないじゃん。

cmdと比較して

>dir

まぁいいか

>dir/w
エラー

Powershell使えないじゃん。

ってかんじかな。

>>393
とりあえず、grepを呼び出すPowerShellのFunctionを作って外部プロセスの標準出力をPowerShellのFuncionの標準入力で受信できるようにしてみなよ

>>394
それってbashの機能じゃなくてUnixのpipe
の機能じゃないんですか？

なんか根本的に勘違いしてませんか？

>>394

bashとgrepって関係ないってわかってますかね？

結局Unix的に使おうとして思うようにいかないってだけですよね。
そういう人たち向けにはWSLがあるだからそれで解決じゃないの？

>>396
grepといったのはたとえだよ
bashのfunctionと同じ機能をPowerShellで実現するのはかなり難しい
function test() {

>>397
cmd, bash, PowerShellのうちどれかひとつを捨てろと言われたらほとんどの人がPowerShellを捨てることになるんじゃないかな

>>398
わざわざPoweshellを使わなくていいんじゃないですか？

WSLでできるものはそれでやったらいいのに
何が気に入らないんですか？

時代が変わったのを理解してないようですね。

>>399
Linux, Windows, Macのどれか一つを捨てろといわれたら？
Linuxを選ぶ人はどれぐらいいるんでしょうね。

LinuxはWSLでWindowsに内包されたんで
LinuxのいいところはWSLで使えばいいだけなのにね。

bashでWindowsのGUIを操作する方向にはならないでしょうし
すみ分けでしょう。

>>400
そのとおり
PowerShellを廃止してWSLのbashに一本化したほうがすっきりする

bash, Poweshell, cmdでも
便利に使えるものをツールとして使ったらいいのに

Emacs+Texで充分だぁっていう人も否定はしないけど、
時代ですよ。

>>402
bashでは機能不足でWindows GUIを処理できないからね。

Windowsが要らなくてLinuxに統一しろとかいう浮世離れした
考え方の人なのかな。

>>403

しつれい

Emacs + TeX

でした。

WSLを利用してあげてください。
開発元のマイクロソフト社とカノニカル社が感謝しますよ。

なんでPowerShellのFunctionの話してるかというと以下の問題があるから
A. batでは引数に絵文字などの非システムコードページの文字を渡せない
B. PowerShellのaliasは引数を付与できない

なお、どっちもWSLのbashでは問題が起きない

でも、わたしはLinuxネイティブな環境しか利用しませんね

start -Verb runas <Command> で管理者実行できることがコマンドプロントに対するPowerShellの優位性だけど、
そもそもbashならsudoコマンドで簡単に同じことができている

>>408
Linuxというよりシェルの話つまりbashとPowerShellの話なので

>>407

だったらWSL使ったらいいのではないですか？Windowsの一つの
機能なんですから。

それとbashとsudoは関係ないよ。わかってるかな？

Windows Subsystem for LinuxはまだLinuxネイティブに追いついてないんだね

/mnt/c以下にまともな速度でアクセスできるようになったら起こして