【Bash】Windows Subsystem for Linux【WSL】6
■ このスレッドは過去ログ倉庫に格納されています
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】5
https://mao.5ch.net/test/read.cgi/linux/1553100855/ >>439
あら、そうでしたか。WSL2触ったことないんで知りませんでした。
やっぱり適当なこと書いちゃいかんな…。 若干スレチだがX410が更新されてる
画像とHTMLがコピペできるようになったらしい >>438
rm -rf / の話は、Cドライブは/mnt/c以下にデフォルトでマウントされていて
rmはマウント先も削除する。ってことに気づかなかったのが原因
rmにはマウント先を消さないように--one-file-systemというオプションが存在する。
隔離された環境だろ?なら消してもOKだなと勘違いしたのが愚か
仮想マシンを使っていても、Cドライブをマウントしていれば同じことになる。 ログインしないと結論が見えないので、結論だけ書いておくよ。
> WSL2のNTFSリンク対応をテストする
> ・Windowsで作成したNTFS上の3種類のリンクを正しく扱える
> ・NTFS上にハードリンクを正しく作成できる(Win32側から正しくアクセスできる)
> ・NTFS上にLinuxシンボリックリンクを作成できるが、Win32側からはアクセスできない
> これから考えると、現時点では、NTFS上のリンクに関しては、
> Win32側で作成し、Ext4に関してはWSL 2側でそれぞれ作成したほうがよいと考えられる。
> 最終的にWSL 1と同じ実装になるとすれば、NTFS上のリンクに関してはどちらで行っても構わないだろう。 XP上でCygwin使ってたときのことを思い出したわ
Cygwinからln使ったリンクはWin32からは認識できないので、
Win32側からジャンクション張って、改めてCygwinでマウントしたりしてたな
たしか、senable.exeを使ったシンボリック・リンクの方はダメだった そんなことするくらいだったら普通にLinux使えよ ネタにマジレスすんなって・・・
台風も過ぎ去り、貴重な休日を何だと思ってる? >>446
DD for Windows でいいじゃん >>451
Cygwinなら昔から問題なくできますよ・・・
cygwin dd
などで検索してみてください・・・ >>453
これな
WSLからwindows上のファイル作れるんだから
windowsからdd出来れば他に何もいらない >>453
よくねーよ
ddって名前付いてるけど全く別物だろ dd for windowsならシリコンリナックスの黄緑のGUIのソフトよく使ってたな ubuntu に sudo のアップデート来たね。早いね。 だいたいこういうのは公開前にdistroのセキュリティ担当に連絡がいってる
足並みが揃ったところで公開とアップデート配信 そういうのはメールでくるよ今回のはしらないけど、セキュリティは期限決まってるからオープンになるでしょ。 WSL2を使ってみてる人に聞きたいんだけど、
WSL2の環境からnotepad.exeを起動して、
WSL2の中のファイルを編集保存とかできるの? >>464
出来る
ただ、書き込み権のないファイルは名前を付けて保存のダイアログになる
Win10.19008.1 へー、すごいな。ファイルは9pプロトコルを使って
お互いにアクセスしてるんだろうってのはわかった。
WSLの仮想マシンの中をネットワークフォルダみたいに
\\wsl$(サーバー)\Ubuntu\\etc\なんたら としてnotepad.exeは読み書きするんだろう。
これは良いとして、プログラムの実行が謎やな。
WSL側でnotepad.exeを実行すると、カスタマイズされたLinuxカーネルがそれを検知して
WSLではなくWindows側のnotepad.exeを起動するということか
CLIだと標準入出力も転送してるってことかな bash単体で正規表現で検索だの置換もできるようになってずいぶん速くなったと喜んでたんだが、
同じようなファイルとかディレクトリの名前をいじくるプログラムをC#で書いてみた
・・・・・
あまりの実行速度の速さに目が点になった
ネイティブUnixでもbashじゃこんな速度でないわ。
コマンドちまちまパイプでつないでいかなくても、
.netライブラリてOS操作に必要なものすべてそろってるんだね・・・ その比較は変だと思うがPowerShellがもうちょっとUnixよりなら良いのになとは思うね >>468
変というかシェルスクリプト相当のことがC#+VSならささっと手軽に書けるんだわ。
PowerShellにはまっていたこともあるが、
こいつはちょっと複雑になると結局.netのライブラリをコールする羽目になるんだよ。
.netをコールするなら複素数だって扱える
じゃ、結局はじめからC#で書いてしまえってことになる。というかなった。
Win7時代あたりのPSは括弧"[]"の扱いがバグってて、
PSからコマンドプロンプト側で処理させるというお笑いバグ回避で乗り切る羽目になったり、
PSいじるぐらいならC#をVS上でコーディングしたほうが
よほどすっきり、手軽に強力なソフトが書けるというのがPSに対する俺の結論
結局bashに回帰した
UnixよりのPSというより、unixコマンドをあらかじめパイプでつないどいてくれたような、
やりたいことが一発処理できる.netライブラリ相当がいいんじゃないの?
.net ・・・君の求めるすべてがそこにある >>467
実行速度に大きな違いがあるのは事実だが、
それに驚いてる程度なら、あんたの書き方が悪いだけだよ
ちゃんと理解してる人は、どこがどういう理由でどれくら
遅くなるかわかってるから、驚かんのよ。
驚いてる → 書き方が悪い → 遅いのは書き方が悪いだけ
というよくある結論にたどり着くだろう > やりたいことが一発処理できる.netライブラリ相当がいいんじゃないの?
Unixのコマンド = 関数だから、
.netの関数を組み合わせてなにかやってるなら、
それは「一発処理」ではないよw >>470
そいつのプログラマキャリア開始時からC#が存在して、bashと比較できる状態ならわかるんだろうよ。
残念ながらこっちはC#が登場するはるか以前からbashスクリプト書いてるんだわwww
そいつをあらためてC#書いてみようって気になったわけさ。
いいなぁ、プログラム開始時からC#がそろっててww
>>471
単なるへりくつだなwww
.namespace mknamedir {
class Program {
static void Main( string[] args ) {
Yaritaikoto
} あ途中で送信しちゃったが
.namespace mknamedir {
class Program {
static void Main( string[] args ) {
System.Yaritaikoto();
}
じゃないと一発処理ではないてことだろ?
まともに会話にならんなお前とはwww >>470
あんま会話しても実りもなさそうだが
>ちゃんと理解してる人は、どこがどういう理由でどれくら
>遅くなるかわかってるから、驚かんのよ。
じゃさ、
どういうプログラムならならbashがよくて、
どれならC#がいいのか
明確な基準示せるよな。当然www
C#以前から活躍してきたperlとの境界も示してもらおうか、
理解してるってことは明確な基準を持ってるんだろうからなwww 屁理屈でもなくても、お前の言う
bashでは一発勝負ではなく、
C#では一発勝負っていうのは
どんなコードなんだって話なんだが? 何を文句言ってるのか知らんが、
まずはお前が、bashで遅くなったってコードでも晒せば?
見れば問題点ぐらいわかるだろ。
お前のコードの問題点は、お前のコードを見ないとわからん Ruby が良い
bash が遅いのは、for ループ内に、多くのコマンド(プロセス)を書いている場合、
そのプロセスの起動が遅い
例えば、10万プロセスを起動して遅くなるとか
ループはパイプじゃないから、並列処理できない。
それに、forループよりも、while の方が速い
一方、Ruby・C# などは、プログラム内でコマンドを起動しなかったら、1プロセスだから 最初から実行速度に大きな違いがあるって書いてあるように
まともなコード同士を比べた場合C#のほうが速いんだよ。
起動時間はC#は遅いけど。
ただね。そんな実行しなくてもわかるようなことに
驚いてるレベルだと、素人くせーなとしか思えんわけ .NETがライブラリ提供の仕組みとして割と良いもんだというのはあるね。
ただ、あの抽象化は問題発生時に手が届きにくいところがあって開発者としては微妙な気持ちにはなるね。
あとPowerShellはDLL呼べて便利だね。
でも単に速く計算がしたいならbashやらzshとpythonの組み合わせがどこでも使えていいと思うよ。使える共有ライブラリが段違いだよ。 >>478
かみあってないよな
わざと外して絡むのを楽しんでるとしか思えない
争いは同じレベルのもの同士でしか成立しない ここは、単純に速いなーと感じたことも書けないインターネッツですか? そんなに速いのが好きなら全部アセンブラで書いてろよ
などと極端な話を投入してみる bashが遅いという感じることは多々あるが、.NETが特別速いと思ったことはない 最近はボトルネックを感じたらRustでかいてるわ。クロスコンパイル最強。
log解析したいときとか、サービス書くときや実行スクリプト書く時にbash使うだけで、まともな処理を書くときには環境揃えて書く。
OS依存処理になるのが目に見えて分かってるのに無駄なコードなんか書く気も起きない。 お前らは.net言語でどんなのを開発しているんだ? \\wsl$\Ubuntu-18.04\etc 以下のファイルって書き込みできないのかな?
理由は権限がないって何となく分かるけど、sudoみたいなことできないの? >>490
確かWindowsの管理者権限でも無理だったよね >>491
仕組み上、9pプロトコル経由のネットワーク共有扱いだからなぁ
権限的にファイルを編集することはできるのにプロトコル経由だと拒否されちゃう
つーかそもそもWindowsでは誰の権限でアクセスしようとしてるんだろう?
最初に作ったユーザーなのかな?9pプロトコルが特定のユーザで
アクセスすることとなっていれば、まあ無理だよね wsl$のアクセスはどっかにユーザのマッピングを持ってて、それ固定になってるみたいだね
・インストールの時にデフォルトユーザ作るけどCtrl+Cで落とすとrootになる、その環境だとwsl$はroot
・デフォルトユーザを削除するとwsl$もアクセス出来なくなる
どこに持ってるんだろ? あー
ubuntuコマンドでデフォルトユーザ変えりゃいいのか
…これ、Ubuntu幾つも入れてたらどう指定するんだ? 漏れは、WSL, Ubuntu 16.04 で、
Ruby で、すべてのパッケージの更新を書いている
ただし、apt を呼ぶなと言われる。
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
#!/usr/bin/ruby
# sudo のパスワードを自動入力する
puts `echo パスワード | sudo -S apt-get update`
# アップグレードできるパッケージを、一覧表示する
puts `apt list --upgradable`
puts `sudo apt-get upgrade -y` >>495
sudoでNOPASSWORD設定しろよ >>493
確かに ubuntu config --default-user root ってやったら
ubuntu の /etc 以下に書き込めたよ
ただし wslconfig /t ubuntu で一旦ディストリを停止しなければいけなかったけど
sudoぐらい気軽には使えないね。
> …これ、Ubuntu幾つも入れてたらどう指定するんだ?
wslconfig /l で入れてるディストリが全て表示される。
複数入れていた場合名前が違ってると思う。俺はUbuntuを二つ入れてるから
Ubuntu-18.04 (既定)
Ubuntu
と表示された。
この場合、下の方がubuntuコマンドで、上の方はubuntu1804 コマンド >>487
Rust良いよね
ワイクソザコナメクジやからコンパイラさんに「テメーここ安全じゃねぇかもしんねーぞ!!!」って切れてもらえるのは非常にありがたい >>498
ライブラリもnull安全だしね、バイナリはいてくれるのはwslでもlinuxでもありがたい。それはそうと誤爆すまん。 Hyper-VにInsider Previewを入れてWSL2を試してみた。
最初、Hyper-V on Hyper-Vが有効になって無くて
WSL2に変換できなかったが、設定するだけであっさり動いた。
これ、すごいね。仮想マシンとは思えないぐらいさくっと起動する。
まあLinuxカーネルは常に起動してる状態で
コンテナ起動してるだけだから当たり前っちゃー当たり前なんだけど
ただの仮想マシンと思ったらぜんぜん違う >>431-432
確認した。その記事は完全に間違い。
開発者モード(おそらくSE_CREATE_SYMBOLIC_LINK_PRIVILEGE )の有無で確かに変わる。
WSL1とWSL2で挙動は全く同じ。
開発者モードが無効の場合、WSLからlnするとシンボリックリンクは作成されるが、
Windowsから見ると、ファイルもディレクトリもどちらもジャンクションになってる。
ただしWindowsから正しく扱えない特殊なジャンクション
開発者モードが有効の場合、WSLからシンボリックリンクを作成すると
Windowsからはどちらもシンボリックリンクになってる。
正確にはdirしたときにファイルにはSYMLINK、ディレクトリにはSYMLINKDと表示されてる
一応記事訂正の連絡はしておいたが、さてちゃんとするんだろうか? >>505
すごいじゃん
hyperVでもこれくらいやって欲しいもんだけど hyper-vのメモリの扱いはほんとに改善してほしいわ
10年も放置しやがって >>505
はー、すげー。これでもうWSL2を使わない理由なくなったんじゃね?
(潜在的にはWSL1の方がパフォーマンスを上げられると思ってるけど)
想像はしたが、カーネルにパッチを当てることで、Windowsとメモリを
共有してるって感じみたいね
>>507
本質的には仮想マシンが使ってるメモリ領域は、どこが使われているか
ホストから知ることができないので、カーネルにパッチ当て無い限り不可能だと思う。
0で埋められていたら、使われてないとみなすか、ゲストOS用ドライバで通信するとか カーネルパッチはオープンソースじゃないの?VMにただ当てるだけで住むならhyper-vにもみ込みあるんじゃね? >>509
本家Linuxカーネルにパッチが組み込まれるなら、
HyperVで動かすLinuxに限ってはその恩恵があるかもしれんね。 Hyper-Vでもゲストのバルーンドライバは結構前から実装されてたと思ったが?
Linux用は無かったとかWSL用にチューニングしたとかなんかな ドライバでやるよりももっと効率よくメモリ管理できるようになったんじゃないかな?
Linuxカーネルが持ってるメモリ割り当てシステムコールそのものをWindowsに転送してる(といいなぁw) ページキャッシュとかどうやって管理してるんだろな? WSLをつい先日初めて使ってみたんだが、思った以上に便利でビビった
どうしても仕事上Windows必須だけど、Linuxコマンドが使いたくなる時あるからな その気になればLinuxデスクトップアプリも動くからな。 Windows Subsystem for Linux に関してよく寄せられる質問
https://docs.microsoft.com/ja-jp/windows/wsl/faq
WSL の対象ユーザーは誰ですか。
これは、主に開発者向けのツールです。特に Web 開発者と、オープン ソース プロジェクトで作業している開発者が対象です。
これにより、Bash、一般的な Linux ツール (sed、 awk など)、および多くの Linux ファースト ツール (Ruby、Python など) を使用する必要があるユーザーは、Windows でそれらのツールチェーンを使用できます。
WSL ですべての Linux アプリを実行できますか。
いいえ。 WSL は、Bash およびコア Linux コマンド ライン ツールを必要とするユーザーが Windows 上でそれらを実行できるようにすることを目的としたツールです。
WSL は、GUI デスクトップやアプリケーション (例: Gnome、KDE など) をサポートすることを目的としていません。 bash が使いたいだけなら
git for windows に入ってた git bash で間に合う
殆どこれで用が済む WindowsはLinuxソフトも使えるようになったので、両方使えるWindowsにしとくのが吉。
ではないか? busyboxの日本語処理がまともなら、これで足りるんだけどな >>521
日本語処理関係でなにか困ることあった? >>522
ls で典型的なSJISダメ文字が消えちゃう(対処方法なし)ので致命的だなぁ
あと、sedやawkが、\:0x5cを付加しないとSJISダメ文字の処理ができない ん? Windows版busyboxの話?このスレWSLのスレだぞ?
busyboxといったらUbuntuのbusyboxの話だと思ったが
WindowsのファイルシステムはUnicode(UTF-16)だが
WSLから見た時は適切にUTF-8に変換されてるから
SJISなんか何も関係ないはずだが
sedやawk、つまりファイルの中身に関してはいい加減UTF-8に統一しとけ
日本語しか使えないSJISを使う必要はない >>524
>>517 からの流れで、
WSLを使う理由がGNU Core Utilitiesをウィンドウズでと考えた場合、
WSLより簡単な代替のひとつとしてbusyboxを上げることもダメなんかね?
配布されてるWindowsバイナリはビルド時に対応オプションついてないんだよ。
ファイルについては、コンバートすりゃいいが、
ファイル名については、リネームしたりしてダメ文字日本語をわざわざ変更しなきゃならない。
ツールを使いたいだけなのに、自分でビルドが必要だったり、SJIS使えないというのは
普通のユーザーには酷だろ。
結果として、残念だがbusyboxを使わないという選択になる。
lsの表示については試してみなよ、インストール必要ないから。 鯖用途でも実運用の為の検証やら総合試験やらでしか必要なくなったしな >>526
WSL自体がLinuxなんだけど?
Windows上でLinux使ってるだけのこと やっぱりWSLでもUbuntu使ってる人が多いのかな? >>525
落ち着いて人の話を聞きなさい
1. ここはWSLのスレ
2. busyboxはWSL(Ubuntu)版
3. busyboxを実行するのもWSL上
ここはそういう前提のスレですよ?
その前提以外でみんな話をしてるんだから
それ以外ならお前に説明する義務がある
ぐだぐだいってないで説明しましょう
何の話をしてるんだ? >>529
今のWSLはWindowsの上でLinuxを使わずに
Linuxアプリを動かせるようにしたものだからLinuxを使ってるとは言えない。
WSL2であれば、Linuxを使ってると言えるが >>525
あと、busyboxはGNU Core Utilsとは全く関係ない
GNU Core Utilsを使わずに、最小限のコマンドを詰め込んだもので
組み込み向け用の道具なんだから機能が少ないのはあえてそうしてる。
可能な限り機能削減を目指してるものに、便利さを求めるなって話
結論としては、WSLを使わない方法じゃなくて、WSLを使えばいい
WSLのスレなんだから >>532
WSLはカーネルが特殊というだけでLinuxそのもの
そしてWSLで使ってるLinuxディストリもカーネルが違うだけで本物のLinuxディストリ
WSLで動作してるUbuntuはUbuntuそのもの OSとしてのLinuxはカーネルだけじゃない
LinuxディストリはOSとして機能するようにいろいろなソフトウェアを組み立てたもので
WSLはそれを使ってる
だから本物のLinux
Linuxを利用してるのにLinuxは不要とか意味不明 WSL1はLinuxカーネルを偽装してるだけ
WSL2はLinuxカーネルそのもの
カーネル以外は本物のLinux
WSLのUbuntuはカーネルが違うだけで本物のUbuntu >>534
WSLで使えるディストリにはDebianがあるんだが、
そのDebianにはこういう物がある。
Debian GNU/kFreeBSD
https://www.debian.org/ports/kfreebsd-gnu/index.ja.html
> Debian GNU/kFreeBSD は FreeBSD のカーネル上に GNU C library を
> 使用した GNU ユーザランドと普通の Debian パッケージ群で構成される移植版です。
さて、このDebianはLinuxのDebianとほとんど同じように使えるわけだが、
Linuxカーネルの代わりにFreeBSDを使ってる。
これははたしてLinuxであろうか?
違うよね? Linuxカーネルを使ってないんだからこれはFreeBSDであってLinuxではない
WSLもそれと同じ。Linuxカーネルと互換性をもたせたWindowsを使ってるので
これはLinuxではない。あえて言うなら、Debian GNU/NT と言うべきだろう
WSLはLinux互換ではあるがLinuxではないんだよ >>538
debianにlinuxなんて意味はないぞ ■ このスレッドは過去ログ倉庫に格納されています