【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/ >GAFAMなんて滅多に使われてないだろ
だから、言われ出したという書き方をしたんだけどね。
>>>548と>>550は一部正しくてGAFAはサービス独占と個人情報保護の文脈で用いられることが多い
うーん。その文脈で使うことが多いの？
投資家が言い出した言葉だったのかなという理解でした。
GAFA が言われ出した頃の MS は株価横ばいで投資対象から外れてた。
>マイクロソフトは1990年代に独禁法の洗礼受けてるし個人情報を扱うサービスをあまりやってないから含まれないのは当然
このせいで株価横ばいだったとも言える。
2010年位にこの問題が片付いて、追いつけ追い越せの快進撃？なイメージ。 >>553
> だから、言われ出したという書き方をしたんだけどね。
言われるほど使われてないよ
読売新聞検索: GAFAM 128件、GAFAM: 2件
https://i.imgur.com/ss6XlMF.jpg
https://i.imgur.com/8hecAno.jpg GAFA as the Big Four, or as the Four Horsemen. BRIC（BRICs）→BRICSになったのと同じだろ >>539
いや、マジですまんが、マジで弾かれる。
自分でソフト名を入れて書けるか試してみてくれ。 >>539
やっぱり書けん。言い方を変えよう。
エンタープライズ向け包括ライセンスはほとんどがそれ。 >>558-560
URL弾かれるなら画像で貼るなりすればいいだろ
知能ないのか？ >>517
pythonの次はpwshだろうなと思う
標準ライブラリ、クロスプラットフォーム性では勝ってるけど、サードのライブラリが少ないし、そもそもpythonの魅力はサードのライブラリなので、ちょっと土俵が違う気がするが
REPLでピボットグリグリするインタラクティブなデータ分析もRやpandasより便利（但し統計関数が寂しい）
二大OSのwin10/ubuntuがCIM準拠&そのうちプリバンドル(忌み子ことwindows powershellの置き換え)する計画らしいので、そうなれば情勢は変わるかもしれん
まあズブズブのubuntu以外は乗り気じゃないけど
pythonのコンパチ確保は各プラットフォーム毎のハードコードで（pathlib、os、 sysやら）保守が全く追いついてないグダグダだし、.net core&CIMベースのpwshならちゃんど保守が行き届くだろうと期待
あとシェルやシス管用途にも使えるぞ！ 30年間継ぎ接ぎ重ねて一貫性もなく、スクリプト言語では最古参な部類のpythonゴリ押しには違和感覚えてる
モダンな言語は沢山現れては消えをくり返してるから、消去法で選ばれた感 Pythonはプログラミング初学にとってはドキュメント豊富とかそういう文脈とは違ったところで取っつきやすいんだもん
言語化あんまされてないけどさ 公式に限れば少なくともpwshの方がドキュメントは充実してないか?
gh topic/command -examples|-detailed... etc
まあニホンゴは機械翻訳で怪しいけれども…
ghはユーザスクリプトのコメントに記述したのもちゃんとman形式にフォーマットして拾ってくれるし、docstringより便利だろう
生pwshでもreadlineの上位互換付いてるし、自作スクリプトすら先読みして、-まで打ってtabでオプション補完してくれる pythonは人力翻訳だからエイゴ苦手な人には優しいね
いにしえの言語とはいえ、先見の明があったからそこまでobsoleteではないと思う
少なくとも後発のjsなんかに比べれば 俺は折角wsl使うんならwin/linuxでシームレスに使えるpwshで統一しよう、って動機で初めたな
rcfileも特に気を張らず書いて共有しても問題起きるのは稀
wsl以前はbash(.exe、有志移植)と/usr/bin/bashで統一目指した事もあったけど、fsの違いが罠
wsl登場で随分良くなったとは思うので、"linux"というOSを勉強する事がモチベならば、win/linuxシェルをbashで統一も現実味を帯びてきたね ごめんわかりにくい書き方だった。Pythonはドキュメントの豊富さとは関係なく（言語化が難しいけど）取っつきやすいって意味
無理やり言語化するなら
型指定が必ずしも必要じゃない（なんかめんどくなさそう）
インデントベースだからぎっちりしてなくて簡単（に見える）
スクリプトっぽい書き方をしても怒られない（感じがする）
ゴリゴリの文系脳に寄り添っている（気がする）
悪く言えばファジーなんだろうけどさ、いやWSLスレで俺はなにを書いてんだろうね… >>572
簡単なシェルスクリプト的な
後からメンテすることを考えず直感的に手癖で書く感じかな
メソッド使わずに殆ど書き下しとか >>573
それをスクリプトっぽい書き方と呼ぶことには反対するが
あなたが言ってるのはユニケージってやつだろうね。
関数を使うのを禁止して共通コードはコピペするらしい。後からメンテすることを考えてない。
メンテナンス不要の開発手法だから後からメンテンすることなんて考えなくていい！みたいなことを言ってる。
https://www.usp-lab.com/methodology.html
> プログラム内部構造も共有分が錯綜しないよう、ワンプログラムワンフローの
> 原則を貫いてます。（ユニケージはシェル関数の記述さえも基本的には禁止しているのです！）
そのユニケージ関係者と思われる人が書いたコピペだらけのクソコードｗｗｗ
https://github.com/ShellShoccar-jpn/kotoriotoko/tree/master/BIN >>574
初学者が取っつきやすいと思う理由を無理やり言語化しただけなんで言葉の定義に触れるのは勘弁してくれ
ユニケージの記法に則って書いても怒られないって言いたいわけじゃないんだ
それ以前の問題というか…まあスレチの話題だしもう触れんから大目に見てくれ >>574
ユニケージ開発手法ってクソみたいな手法だな ユニケージが具体的に何を指すのかはよく知らん (社長だか代表だかの講演聞いたことあるけど) が、使い捨てられる短くて有用なイディオムを沢山持っとくのは良いことだと思う それはそうと今日びパンピーのgithub晒してこき下ろすって凄いな ユニケージって、知らなくて調べてみたら、そんな書き捨てスクリプトというようなことではありませんね
>>573 の内容の方がしっくりくるかな
処理をべたで書いても動きますよみたいなことですよね
特にjupyterみたいな環境だとちょこちょこ動かしながら使えるからとっつきやすいだろうね >>579
書き捨てスクリプトってどこから出てきた話なんですか？
ユニケージは
> 後からメンテすることを考えず直感的に手癖で書く感じかな
> メソッド使わずに殆ど書き下しとか
と言ったんです。 >>577
> 使い捨てられる短くて有用なイディオム
ユニケージにそんなものないよ >>581
どこにもないね
メンテナンス不要→再利用や更新不能→使い捨て
みたいなイメージだった
作った物がそのままずっと使われるのであれば、「捨て」ることにはならないから違うんだろうね 作った物がそのままずっと使えるなんてありえないぞ
メンテナンスは絶対に必要になる
メンテナンスは絶対に必要になるのに
そんなこと必要にならないですよと嘘をついて
メンテナンスできないやり方を押し付けてるのがユニケージ >>560
すまん。寝ぼけて間違えた。
E5 じゃなくて E1だった。すまん。 先週あたりのアップデからnvimの起動時間が異様に長いなと思って--startuptimeでログ取った
存在しないはずのクリップボードを探しに5秒くらいかかって計7秒だった
もしかしてwslgとやらと関係あるかな？ubuntuだけどaptとnvimは数ヶ月は更新してない
wslg.exeの存在は確認
guiやマウス、メニューの設定は対応してなくても無視されるからとwinのgvimと共有してた
.gvimrcへclipboard等の設定を移して1.5秒、解決
同じような人居そうなのでメモ
windows上のgvimはコンソールのnvimより起動速くて1秒なんだけど、これはフォークの差なのか、ネイティブアプリのとの差なのか bashrcとかzshrcになにか設定してる？
最小構成でも確認できる？ export PULSE_SERVER=tcp:$(grep nameserver /etc/resolv.conf | awk '{print $2}'); windowsに移行して2か月経ったけど不満ない
色々なアプリやゲームが動くことに感激だわ
vscode+wslも十分快適
jdimがないのが唯一の不満(Sikiも十分出来がいいけど) Windowsapp内にあるubuntuとsystem32内にあるwslの違いが分からないのですがどなたか教えて頂けませんか >>593
まずもともとはbashとして作られた。Ubuntuしか使えなかった。
bashを起動するからbash.exe
そのうちUbuntu以外も使えるようになった。
互換性を保つ必要があるからbash.exeを残すのは当然として
bash.exe だとUbuntuのbashなのか、SUSEのbashなのかわからない
ubuntu.exeやsuse.exeの登場
wsl機能はOSの機能だから、OS のシステムツールとして管理機能が必要
つまりwsl.exe の登場。システムツールだからsystem32にexeがある。
一方wsl機能を使って起動するディストリは
Windowsストアアプリとしてインストールする。
ストアアプリはユーザーごとにインストールしているものが異なる。
つまりubuntu.exeなどはユーザーごとのディレクトリに存在する 話題になってたwinのbashコマンド呼ぶとuid 0のログインシェル(pwshとか)立ち上がる挙動面白いな
function bash(){wsl bash $args}
みたいにしとけばいいかな
互換性で残すというが、古いのはbashコマンドでbashが呼ばれる前提で書かれているはずなので、ちゃんとwinからwsl bashを呼ぶコマンドに置き換えた方が互換性的にもいいのでは？
ところでスクリプトからbash -cでwinのシェル関数呼ばれたっけ？
上の定義をbashfunとして、set-alias bash bashfunとでもしておけば大丈夫だろうか
標準aliasは少なくともスクリプトでも呼べたはずだが、$profile記述のユーザー定義はどうだっけな…？ >>594
ご丁寧にありがとうございます
熟読しましたが頭が悪く半分程度しか理解できませんでした
wsl.exeはbashをwindowsで起動する機能で、ubuntu.exeはさらにその1段階上という認識でいます
ubuntu.exeを基本的に使用してwsl.exeは使用する余地がない(ディストリビューションがないから)との考えでいます 複数のWSLのインスタンスが入ってればwsl.exe --listで眺められるし
wsl.exe -d で指定して動かすこともできる ubuntuも18/20のlts入れてubuntu.exe呼ぶと何が起きるか気になる >>600
ubuntu18.04.exeとubuntu20.04.exeでディレクトリごと別れてた気がする
それはそれとして基本的にwsl.exeを使って起動すればいい >>596
wsl.exe：WSLを管理するためのコマンドライン・ツール
https://docs.microsoft.com/th-th/windows/wsl/reference
ubuntu.exe：WSLでディストリビューション"ubuntu"を起動するためのランチャー
各ディストリビューションを起動するために、[ディストリビューション名].exeというランチャーが存在している。
https://docs.microsoft.com/en-us/windows/wsl/install-on-server Linuxに興味あるんならいまどきPCは2台以上持ってない？
Linux専用とWindows10+wsl
Linux用はHDDが壊れてSSDに入れ替えた古いノートPC このスレ、そのgcってコマンド何？って発言飛び出すレベルでwindowsの知識皆無なので、逆なのでは
windowsへ移行の架け橋
MSの狙い通りだね >>596
ねぇ、なんでそんな認識をするのかがわからない
思うんだけどさ、>>594を読む前に君、答えだしてるよね？
そして君の答え（＝間違い）が正しいと思いこんで>>594を読んでるよね？
自分の答えが正しいことを確認するために>>594を読んでいるわけで
自分の答えが間違っているなんて、全く考えてないでしょ？
理解できないのは自分の間違った考えと整合性が取れないからなんじゃないの？ 思い込みの決めつけユーザーだろう
MSの説明を読んでね でいいんじゃないのかな >>594
>bash.exe だとUbuntuのbashなのか、SUSEのbashなのかわからない
どっちも一緒だよ馬鹿じゃねーの？ そもそもbashじゃない件も忘れるなよ
いや忘れろ、か
bash.exeを >>273あたり参照
windowsにあるbashコマンド(cmd/pwsh)は
引数無しならデフォルトディストロのuid 1000のシェルでログイン
スクリプトか-c引数渡せばそのシェルで実行する
という機能であって、bashとはなんの関連もない >>607
ディストリが違うだろ？
お前は何を言ってるんだ >>609
-cでスクリプトを実行するとかいう機能はbashの機能だよ >>611
どのシェルでも-cは慣例としてサポートしてるだろ
pwsh -h
俺みたいにwsl内でもpowershell使ってるなら、（windows上から）bash -cで走るのはpowershellコマンドだよ
zshでもkshでもtcshでも似たような挙動だろう オプション含めそっくりそのまま引数を渡してるかはわからん
bash.exeが引数-cを解釈して、改めてシェルを呼んでるのかもしれん
暇人検証求む pwshは-cと同義の-commandオプションをサポートしているから、-commandがもし(wsl内の本物の)bashに渡ればエラー吐くんでない？ win上で走るスクリプト内からbashコマンドで呼ばれるのがwsl内のbashかpwshかはエラーコードで判別付くかもしれんな
-commandを受け付けない他のシェルとの区別は付かんけど あとbash -c "bash -c command"で確実にwinからbashは呼べると思う
pwsh@wsl> bash -c command
でbash@wslが起動するんだから
wslで提供されているディストリには全てbashがプリインストールされているはず エスケープで頭痛くなりそうなので
function bash(){wsl bash $args} bash -c "bash -c cmd"はwinからでもbashを使ってないlinuxからでも合法なコマンドかな？
wsl上のunix系シェルなら無駄にネストしてbashを呼ぶ
win上で実行すればPATHEXTを参照して初めのbashはbash.exeと解釈され、wsl上で何らかのシェルを立ち上げる
二番目のbashはそのシェル上で/usr/binかそこらのbashを呼ぶ
実用性は皆無だけど面白い UbuntuのbashとopenSUSEのbashは同じものかもしれない
bash.exeでどちらのbashが開かれても、bash自体は同じかもしれない
でもUbuntuのbashを開いた場合とopenSUSEのbashを開いた場合では大きな違いがある
bashを使いたいのではなく、bashを通してUbuntu/openSUSEを使いたいのだから Win側のbash.exe は wsl.exe -e /bin/bash を呼んでるね
(bash.exe -c /bin/sh とかやるとwsl.exe -e /bin/bash -c /bin/sh になる) >>619
ホームディレクトリや/etc以下とかを見てみ
ディストリが違ったら中身も違うからさ（ぷぷぷ SUSE系ってsystemdなしでまともに動くの？
yast2弄ってるだけでsystemd云々で怒られた覚えがあるんだが いろんなOSで動かせるアプリが特定のinitに依存していたら
そっちのほうが大問題だけどな >>624
bashの話だろ
それ以外のファイルやディレクトリの話は誰もしとらんｗ あ、もしかしてbashをディストリビューションか何かと勘違いしてんのかな？ >>627
あのー、Ubuntuのbashと、SUSEのbashを
区別できないんでいいんですか？って話をしてるんですが？
bashが動く環境が違うんだから区別しないとだめだろ >>629
やっとわかって誤魔化しフェーズに入ったかｗ 言葉たらずのバカが人を罵倒してるだけってLinux版らしくていいよねｗ >>631
最初からこれの話をしてるんだけど？
>bash.exe だとUbuntuのbashなのか、SUSEのbashなのかわからない
最初から、bash.exeだと環境がわからないって話なのを
今理解したんですか？ bash.exe で起動するのは既定のディストリビューション。
規定のはwslconfigで設定 だから特定のディストリで起動するためのコマンドが必要になる >bash.exe で起動するのは既定のディストリビューション。
え？ マジの汗臭デブかガリキモオタクぽくて安心するわ
必死すぎ >>639
「え？」って言っただろ！
なにか反論してみぃやぁぁあｌ！ もうさ、「え？」って言ってるのに行間が読めないやつ多すぎ
アスペなん？俺が「え？」って言えば普通わかるやろ LinuxモドキのWSLなんぞ使うやつはアホばかりなのがよくわかる流れ 使いどころがわからない情弱さをアピールしているんだろうw PATHの設定次第ではcygwinやmsysのbash.exeが起動するかもしれないがスレの流れを考えればWSL限定だろう 開発用には向いているかもしれないが
本番、商用には向かないな ジェットストリームなんですか？か。
Linux板で「みんなの自動翻訳＠TexTra」の名前が出てきたのが去年の3月頃と割と最近みたいだから、
まだ知られていないマイナーな翻訳サービスが世界のどこかにあるかもしれない。
https://mao.5ch.net/test/read.cgi/linux/1582032306/732
> 732 login:Penguin 2020/03/12(木) 22:55:37.42 ID:nyH5ITMQ
> ちなみに使ってOKな機械翻訳もある
>
> 「みんなの自動翻訳＠TexTra」はオープンソース関連文書の翻訳に唯一使える機械翻訳サービス
> http://www.nofuture.tv/diary/20190917.html ■ このスレッドは過去ログ倉庫に格納されています
