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

仮想マシンにWindowsと連携機能をつけたがWSL2

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

>>152
連携機能って具体的に何？共有フォルダとかじゃないよね？

>>153
WSLがどういうものか調べてからレスしろよ

>>153
> 連携機能って具体的に何？

仮想マシン＝結局は別のマシンにすぎない。
仮想マシンはリモートにある別のLinuxマシンを使ってるのと大差なく
Windowsの機能が強化されるわけじゃない。
それじゃmacOSのような快適さは得られなかった

WSL2は別のマシンがあるように見えず
WindowsがまるでLinux機能を備えているかのように動く
だからmacOSを超えた。もちろんLinuxもね。

仮想マシン上のリソースを「透過的に」利用できるところがウリ
完全に「痒み」が取り払われるまでには至ってないけど、便利になったもんだ

WSLgにも期待

>>155
「まるでLinux機能を備えているように動く」とか文芸的な表現はもういいからw
具体的に言えよそれで充分。
例えばどんな使いしたときそう動くんだよ？w

> wsl お好きなコマンド(newline)
以上になんか言う事あるか？

相互にパイプで渡せたり出来て便利だけどな

定型文
wsl cmd |clip.exe

と思ったらwslgでXサーバが標準で付いてきたらXのクリップボード使えばいいか

なる
xselでWindowsとクリップボードを共有できるね
ただ、まだ日本語は化ける

XじゃなくWaylandだからxselじゃなくWayland用のを使う必要があるんじゃね

clip.exeじゃなくてset/get-clipboardを使ってれば、win上ではシステムに投げ、linux上デフォルトではxclipに投げるはず
特に設定してなくても動いてる感じ(よく分かってない)

man xclip眺めたところ履歴はサポートしてないっぽい？
田+vで出るwinのクリップボード履歴を重宝してるんだけど

>>164
色々絡んでいんてよくわからん。
https://news.mynavi.jp/article/20210424-1876533/
WSLg用のDistroが動くようだ。クライアントはRDPだね。

>>164
そうだった
ただ、wl-clipboardでも日本語化けるのは変わらず

文字化けは単にエンコードの問題ではなくて？
コマンドラインで受け渡しならget-content -encode 色々 で指定できるし、毎回面倒ならスクリプトにしてパス通しておけば？

マウス操作のコピペで化けるなら、どこで設定するのか分からんごめん

コンソール対応アプリなら、元々xclip等外部コマンド呼び出しでシステムのクリップボードと同期してるので、ここで同様にエンコード指定ができる
(vimならg:clipboard)

多分標準コマンドで推論してくれるの無いよね？
nkfとか推測機能のある外部コマンドに掛けてみては
パイプ越しと画面コピペ越しで違うかもしれないから両方
フィルター内に推測&変換まで組み込むと、今度は時々化ける謎現象に悩みそうだから調べるだけで

>>158
Windows上でbashが使える
仮想マシン上でbashが使えるんじゃなくて
Windowsマシン上でbashが使える

色々弄ってるんで標準かどうか不明だけど、bash.exeはsystem32以下に見た覚えがある
これがwin用シェルとしてbashを使いたい人用では

外部コマンド揃ってるかなど、快適かは使ってないので不明
手元に.shがあるけどwsl入れる程じゃない時用？

windows詳しくないからまだ探索中だけど、System32はユティリティの宝庫だね
wsl側メインに住まいたいなら主な恩恵はここから？

ごめん
起動してみたらwslが立ち上がった
ただのクライアントというオチ、忘れてください

当初のBash on Windowsのいう名称のせいで未だに勘違いしている人いるんだな

>>175
お恥ずかしい
ログインシェルの設定(pwsh)を迂回して、bashと専用のコンソールでwslに接続する非常口、という認識でいいのかな？

サードパーティだけどwindows用bashもgit等開発ツールキットの類によく同梱されてる
linuxでなくbashが必要なのならそれ使えばいいよ

wslコンポーネントの方が後発、かつ役割がbashでないのに名前衝突起こすからタチが悪い
紛らわしいから名前変えろ

>>176
Windowsにログインシェルなんて無い
ログインシェルと呼べると言えるのはせいぜいエクスプローラーだ

Linuxで言えばデスクトップ環境からターミナルソフトを起動するのと同じ
pwshかcmdか、そしてbashを起動できるようになった

そのWindows上でbashが起動できるように見せている仕組みがWSL2だ
もちろんbashだけではなく様々なLinux用ツールがWindows上で使える

>>177
なんの名前を変えろって言ってんの？

もともとWindows用のコマンドとLinux用のコマンドは全く別
コマンド名が全く違うというのはたまたまWindowsに有利に働いていた点で、
macOSだとまったく同じコマンド名なのにLinux版と互換性がないから問題が起きてる


WindowsのコマンドとLinuxのコマンドで名前衝突起が起きてるのは
sort と date ぐらいでしょ？ それだってWindows版はsort.exe というように .exe が付いてるから
WSL の bashやシェルスクリプトとかから、間違ってWindows版を呼び出すことがない

Windowsからbashを実行するときは、Windows版のbash.exeが実行されるが
もともとWindowsに.exeなしのbashなんて無いわけで名前衝突してない

winにはpathextあるから省略できるだけで、普通にシャドウィングするぞ

msys2使ってて困る人を見かけるし、サードであろうと普及しているのを無視するのはいかがかと

あとこのbashなるモノはpasswdの記載に従ってシェルを起動するので、ログインシェルを変えてるとbashじゃない
pwshにchshしてるからbashでpwshが起動する
とても面白い

>>176
初期化時のデフォルトユーザーとは別のアカウントをメインに使ってる時の挙動かな、お行儀のいい方法

winからbash(.exe)を引数無しで起動すると、初回起動
その場合はbashコマンドからを設定したユーザーを作っておいて、bash -l user指定すればbashが呼ばれる

デフォルトユーザーは初期化時以外触らない、上位互換なwsl(.exe)を使う
でいいのでは

>>181
「普及している」という考え方が間違っている。msys2が普及していないからMSはwslを投入したし、ユーザーも支持している。
そもそもmsys2使っている人間は想定ユーザーじゃないだろ。MSからすればmsys2を使っていないユーザーをwindowsに引きつける方がはるかに重要。

wslg面白い
linux側でGUIアプリをインストールすると、
Windowsのスタートメニューに登録されてそこから起動できる
gimp,visual studio codeなんかはアプリのアイコンになってる

>>185
wineのwindows版みたいな感じかな。
便利そうだな。

>>185
WSLgはLinuxデスクトップをrootless表示するだけでなく、Windowsデスクトップと統合してしまうの？
Windows上で、次のように利用できるとありがたいのだけどね。

仮想デスクトップ１：Windowsデスクトップ
仮想デスクトップ２：Linuxデスクトップのroot windowを全画面表示

>>187
俺はそう別々にしてほしくない。
むしろ余計なことに感じる。

fontforgeはexport GDK_BACKEND="x11"で動作した

Windows 10 Insider PreviewのLinux GUIアプリ実行サポート、現時点ではHaswell世代以降のCPUが必要

日本語入力はどうするの？

>>187
Xephyr 使えば出来そうだけど、User DistroにもXサーバが必要になるね

今の使い方だと、WSL2 + VcXsrvとか、MobaXtermでroot window表示してる。

同じことをやろうとすれば、WSLgの場合では、Xサーバーをネスとする必要があるの？

例えば、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

このyarnファイルは、Linux, Mac 用に書かれていて、
WSL で、Linux側から呼び出しても、yarn.jsが呼ばれるようになっている

次のレスに、yarnファイルを書く

#!/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

command_exists() {
command -v "$1" >/dev/null 2>&1;
}

if command_exists node; then
if [ "$YARN_FORCE_WINPTY" = 1 ] || command_exists winpty && test -t 1; then
winpty node "$basedir/yarn.js" "$@"
else
exec node "$basedir/yarn.js" "$@"
fi
ret=$?
# Debian and Ubuntu では、node じゃなくて、nodejs
elif command_exists nodejs; then
exec nodejs "$basedir/yarn.js" "$@"
ret=$?
else
>&2 echo 'Yarn requires Node.js 4.0 or higher to be installed.'
ret=1
fi

exit $ret

やっぱPATHEXTはよろしくない仕組みだな
しかし消しちゃったら問題起きそう

>>178
SHELLがexplorerなんだけど。

SHELL=CUIっていう概念な人にはわからないとおもうけど。


explorer以外にも設定することは可能。

Shell Entry
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738733(v=ws.10)

>>197
だからそう書いてあるだろ
同じこと書いて何がしたいの？

> Windowsにログインシェルなんて無い
とかアホな事言うからだろ

最近2度目のwslを弄ってみた

PS C:\WINDOWS\System32> wsl
と打ち込んだら勝手にubuntuが立ち上がるのね

Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

System information as of 2021年 5月 1日 土曜日 11:52:16 JST

System load: 0.45 Processes: 8
Usage of /: 1.7% of 250.98GB Users logged in: 0
Memory usage: 2% IPv4 address for eth0: 172.17.89.142
Swap usage: 0%
This message is shown once a day. To disable it please create the
/home/akai/.hushlogin file.
akai@note:/mnt/c/WINDOWS/System32$

でここでubuntuのコマンドが打てるわけか
試しにfirefoxと打ち込んだが駄目だった
でもVcXsrvを立ち上げてやってみたら
akai@notemnt:/c/WINDOWS/System32$ firefox
[GFX1-]: glxtest: libEGL initialize failed
[GFX1-]: glxtest: libEGL initialize failed
[GFX1-]: No GPUs detected via PCI

その後見事にfirefoxが立ち上がった
これって最近出来るようになったの？
そのfirefoxからの打ち込みです

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

>>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前提のツール

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