【Bash】Windows Subsystem for Linux【WSL】4

Install the Windows Subsystem for Linux
https://docs.microsoft.com/en-us/windows/wsl/install-win10

前スレ
【Bash】Windows Subsystem for Linux【Ubuntu】3
http://mao.2ch.net/test/read.cgi/linux/1528141781/

>>641
そもそもゲイツが潰れかけてたアップルに資金提供して蘇生させたんだがな

Send salt for Apple.

大流行の“塩◯◯”ブーム！今秋に新登場の「塩りんご」って何？
https://news.cookpad.com/articles/3007

str=`ruby -e 'print "赤い糸".encode( "CP932" )'`

grep -ir "$str" ./*

"赤い糸"という文字列を、Ruby で、sjis に変換して、
(Ruby にはデフォルトで、nkf が入っているので、Linux にはnkf を入れていないため)
それで、Windows側のsjisのファイルをgrep したら、

「バイナリファイル ./桃子.txt に一致しました」とひとまず一致したけど、
sjis のファイルは、バイナリファイルとみなされた

一致箇所が複数あるけど、何回一致したかはわからないし、一致した行もわからない

ただし、ファイル名は自動的に、UTF-8 に変換されている

-a

いい加減SJISのファイルを辞めるべきだろ
なんで日本専用の文字コードを使うんだよ？
海外対応考えてないのか？

ヘッダーにcharset=Shift_JISとある5ch.netの悪口はやめたまえ

そんなあなたに古典ツール nkf。今となっては速度面で見劣りするけど便利なので生き残っている。

rgとかpt使えば、grepみたいに遅くないし、utf/euc/sjis混ざってても探せるのに

grepが遅いようにみえるのはディレクトリツリー検索でファイル除外できないからであって、単体ファイルの検索ならgrepのほうが40%近く速いよ。

>>790
だいたいExcelのせい
インターネットバンキングからcsvおとして解析かけるのに一旦utf-8に変換しないといけないし。

全角半角混在前提なSJISは良い文字コードなんだけどな。

多言語の文字を混在出来ないけどね

ロ、ロシアとギリシャなら…

5ch(2ch)するだけなら問題ないかw
つうかDATがSJISなんだよな・・・

5chもグローバル化の波に乗るかもよ？笑
多言語板が出来そうだが、キリル文字の荒しとかでそう。
まあそしたらＡＡ香具師とか死にそうだけど。

utf8の板もあるでしょ

>>797
ロケール切り替えれ

JISとソート順が変わるから無理でしょ

>>802
馬鹿なの？

🐧Д가
5chの場合、全部SJISで一部の板は文字参照としてunicode文字が表示できる
キリル文字はそもそもSJISに収録されてる(unicode前から顔文字に使われてたし)

ファイルアクセス超遅い
configure終わらん
virtual boxにいれたopensuseのが速い謎

virtual boxのが速いってのは
ちゃんと仮想osと共有してるホストwindowsのディレクトリで
仮想oSから作業しての話ね。
ほんと謎

そりゃWindowsと協調して動作するよりも
Windowsと切り離して動かしたほうが速いだろうなとしか
当たり前じゃね？

物にもよるけどVMだとディスクキャッシュが効いて、ホストで動かすより速いこともある。
ディスクのスピードテストしてみれば分かる。

vboxsfとしてマウントしたwindowsディレクトリだから
当然windowsとは協調動作してますよ。

だからそれ以外の話だよ

システム環境をチェックするconfigureが
共有ディレクトリを多量にアクセスするわけなかろう

ロケールを変えて問題解決できたためしがない。

cofigureが遅いのは、ファイルアクセスのせいはあまり関係ないと思う。
makeはそれほど遅くない。
cygwinと同じでforkが遅いせいだとおもう。
cofigure遅いといっても、cygwinにくらべたら、wslはだいぶ速い。

でも、native linuxからするとくそといいたくなるが。

Windowsにfork相当の機能がないのがそもそもの問題なんだよな。
今のMSならカーネルにforkもしくはforkが速くなる機能を
実装してくれると思う。

WSLってWIN32API使ってるんだっけ？

>>813
なるほどそっちか。
たまにfork自体を失敗するMSYS2よりマシかもしれんけど。
となるとVMつかった方がいいな。

>>815
使ってる部分もあると思うけど、NTカーネルAPIがWindowsの
本当のAPIでそれを利用する形でWin32APIが作られてる。
それと同じレイヤーでWSLが実装されているわけだから
基本的にはWin32APIを使わずにNTカーネルAPIを呼び出してるはずだよ

>>816
VMは実質二台のパソコンを使うようなもので、
ホストOSとのデータのやり取りが面倒なんだよ。

つまりWindowsのテキストエディタを使って
プログラミングしてLinuxで動かすとかね。

>>817
だったらfork相当の機能がなくても困らないじゃん。
いにしえのPosixサブシステムと同じことすればいいんだし。

>>819
> だったらfork相当の機能がなくても困らないじゃん。
なんで？

> いにしえのPosixサブシステムと同じことすればいいんだし。
だからいにしえのPOSIXサブシステムも遅かったんだろ？

>>814
RtlCloneUserProcess

>>821
あー、はい。そのAPIがLinuxのforkに比べて遅いんでしょうね。
調べてくれてありがとね

>>818
wslで/mnt/c経由でアクセスするのと、
virtual boxで /media/... 経由でアクセスするのと全く一緒だけどな。

>>823
一緒だからこそ、そこで差は出ないってことだよ。
つまり、差がでるのは共有ディレクトリではない所だということ
ここまですぐにわからんかね？

あ、速度の話と勘違いしたわｗ

>>823
virtualboxで/media経由でアクセスするには、共有フォルダの設定が必要で、
さらに仮想マシンのOSにGuest Additionsをインストールしなければいけない
もちろんOSのインストールも必要だな。

気軽さがぜんぜん違うよ

>>825
WSLでxで日本語使えるまでの設定どんだけ苦労したかｗｗｗ
絶対virtualboxのが設定まで含めて楽w

>>822
余談ですが、WSL Debian で sh (dash) を ksh93 で代用した時は、fork 処理が sh より速かったように思います。

>>827
http://magicant.txt-nifty.com/main/2007/12/post_b430.html

前にも書いたけど、WSLのforkが遅いのはウイルス対策ソフトの影響もあるようだ。リアルタイム検索止めるとforkが早くなる。

defender糞遅くなるからビルドするときとか毎回切るわ

>>827
ksh93は、他のシェルならforkを使うような場面でも
forkを使わずに（無理やり？）実現している場合があるので
fork処理が速いではなく、fork回数が違っている可能性が高い

っていう話が>>828にも書いてあるな

>>826
> WSLでxで日本語使えるまでの設定どんだけ苦労したかｗｗｗ

WindowsがあるんだからXいらないよ

LXDE試したことあるけど、デスクトップ環境を部分的にしか動かせない。
WSLでそこまでやるのはもう趣味レベル。


単にGoとかのスクリプト動かしたいけどWindowsだと面倒くさい時にしか使わない。
コンパイルやビルドは素直にVMでやったほうがいいわ。

>>833
日本語ファイル扱えねーだろ

扱えるけど？扱えないものの名前言ってみ

𡈽𡌛𡑮𡢽𠮟.txt

>>837
普通にメモ帳でそのファイル名で保存できた
っていうかそれ、日本語ファイル名じゃないしｗ

ローマ字だってちゃんとした日本語ですよ？

>>831
それ、聞いたことある。自分ではkshをうまく扱えなくて、つかってない。

>>839
837のどこら辺がローマ字なの？

hyper-vのパススルーディスクで、別SSDにインストールしたubuntuを使うと、I/Oのベンチで
windows側と比べて95%ほど出てるのでとても快適な環境なんだけど、linuxゲストだと
hyper-vの動的メモリ管理がひどくて、2GBから16GBで動的割り当てにしていると、linux側で2GBも
使ってないのに、すぐに16GB確保されちゃう。
・WSLは遅いし
・virtualbox with hyper-vは、別ドライブからの起動がうまくいかないし
・vmwareはhyper-vと仲悪いし
で、決定打に欠ける。
メモリ安くなったから、64GBにして解決するのもありかもしれない。

>>838

ファイル名はOSの管轄だからメモ帳とは関係ないだろ

NTFSのファイル名はそもそもUTF16が仕様だし
NT3.1でも対応したフォントさえあれば可能

>>843
batはロケール依存。今もUnicodeでファイル名を渡せない仕様。

>>842
Dynamic MemoryなんてWindowsゲストでもうんこでや(ﾎﾞｿ

>>843
カーネル回りはUnicode前提で作られているけど
上部はWin9xとの互換性のためにShiftJISを採用
W系文字列とA系文字列を変換しつつ動いてる。

VC8.0からワイド文字がデフォルトに変更された。が・・・
未だにマルチバイトでビルドされたソフトも存在する。

それがOSの機能・仕様となんの関係が

>>844
> batはロケール依存。今もUnicodeでファイル名を渡せない仕様。
それはお前がコマンドプロンプトをsjisで起動してるからだろ
chcpでコードページを切り替えろよ

>>846
> カーネル回りはUnicode前提で作られているけど
> 上部はWin9xとの互換性のためにShiftJISを採用

上部ってなに？ Windowsと関係ない
一部のアプリがSJISを使っているからって、
WindowsはUnicodeなんだけど

>>849
マルチバイトでビルドされたソフトには異なるロケールで引数渡しできない。文字化けする。>>846 さんの言ってることが現実。
Windows向けPerlディストリビューションのStrawberry Perlもマルチバイトでビルドされたソフトのひとつだよ。

だからアプリの問題ですよな。
OSと関係ない

>>852
残念ながら、OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すのでアプリの問題じゃなくてOSの問題なのよ。
つまり chcp 65001 しててもアプリにはコードページ932の文字列が渡される。アプリ側ではどうしようもない。

> OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すので
ダウト。そんな事しない

>>854
え？ほんまでっか！？

別に引数渡ししなくてもプロセス間で情報をやり取りする方法あるしな。

chcpはファイル入出力のコードページには何も影響しないよ。

ファイル入出力？何言ってんだ？そんな話はしてねえぞ。

OS（カーネル）はそんなことしない、引数の値をただ渡すだけ。そもそも、OSはどこにも噛んでない。
シェルの問題、パイプを噛ませるならともかく。

Visual Studio でビルドしたバイナリだとmain()で始まるバイナリであっても、
GetCommandLineW() と CommandLineToArgvW()でオリジナルに近いコマンド引数をUTF-16で得ることはできるね。

>>849
実際に試しもしない馬鹿

>>861
何を試すか示されてないのに、
どうやって試せと？ｗ

お前なら何を試すんだ？

ここでのOSの機能ってのはNTkernel<各種サブシステムを含む＜コマンドラインを含む標準機能
って定義で揉めているの？

また文系が本質に関係ない所で暴れているのか

ファイル名の話をしてるかと思ったら突然batがどうこう言いだして次はAPIか
何がやりたいのやら

カーネルがUnicodeでシェルがShiftJISだった
それだけ

コマンドプロンプト自体は少しずつ進化していってる。
昔は表示できない非SJIS文字が多かった。単にchcpしただけでは対応できなかった。

>>863
そうじゃない。

OSはAPIを提供している。
その中には古いOSやアプリとの互換性を保つためのAPIもある。
その互換性を重視したAPIを使ったアプリの仕様は
アプリの問題でありOSの問題ではないということ

>>865
> カーネルがUnicodeでシェルがShiftJISだった

それだけだと中国でもShiftJISみたいだろｗ
それにシェルとコマンドプロンプトの違いもわかってない。
Windowsにおいてエクスプローラーもシェルだし、こっちは完全Unicode対応

Windows NT系は最初からUnicode。コマンドプロンプトもUnicode対応だが
互換性のためにデフォルトでは「Unicode対応でないプログラムの言語」の設定に
対応したコードページになっておりこれは変更できる。

ここまでかいて「それだけ」と言えるんだよ

古いAPIをいまだに使ってるライブラリが存在するのが問題ってのは全然問題じゃない。
互換性は必要なのだからOSの問題でもない。アプリもメンテが大変だから対応でなくても仕方ない。
できないことをやろうとする利用者の問題だろ。

取り敢えずおまえらが重箱の隅をつついてヽ(ﾟ∀｡)ﾉｳｪ―ｲってやってるってだけはわかったわ
そんなに文句垂れるならVM使うなり、サブマシンをサーバー化してSSH/MOSH,RDPでつなぐなりすればいいだけ。
WSLは成長途中で成熟すらしてないのに文句垂れるのはアホ。MsWinだって温故知新の如く開発をしている。それでもIEやレガシーシステム捨てないような阿呆のために互換性を捏ね繰り回して考えている。
我々利用者は限られた選択肢をどうするかだけだろ
利用者として要求するならインサイダープログラムにでもさんかしてフィードバックでもしろ。そうじゃなきゃ知識ある人間が文句垂れんなよ。

>>870
そういう人どこにでもいるから気にしない。
WSLには本当に感謝してる人もいるってことを忘れないでね。

sjis は、国際化されていない。
日本国内だけしか使えない

一方、UTF-8 は、すべての国(多国間)で使える

だから外人は、sjis 対応では作っていないから、ほとんどのアプリでバグる。
漏れら日本人が、言語一覧表に表示される、何百もの言語に対応しないのと同じ

ただ、WSL がすごいのは、Windows側のsjis のファイル名を、
Linux側では、UTF-8 に自動的に変換して、読めるようにしている

>>872
逆。Unicodeのファイル名を可能な限りsjisで読めるように擬態してきたのがWindows NTのすごさ。

どっちでもよい。
単純にWindowsの開発が凄いってことだ

Windows界隈でUnicodeというとUTF-16を指す、よね？
MSがすべての文字は16bitで固定的に表現できるって言ってた気がする

UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。
SJISの並び順を維持したままソートするのがWindowsNTの地味な偉さでそ。

ソートしてるのはOSではなくてアプリでしょ？

厳密にはアプリがソートする時に使うSJIS互換の比較関数をWindowsNTが提供している。もちろんアプリはそれを使う義務はないけど。

アプリもAPIもOSの一部の機能を使ってるからOSが基本だな。
リストビューとかソートするプログラムもソート順だけ指定してあとはOSにお任せ。

>>874
ほんとそうですね。Linuxの10年先行ってる。

Windowsではなく、WindowsNTを作ったカトラー(DEC出身)がすごいのだ

むしろWindows1.0〜Meとの互換のためにNTの潜在能力を出し切れていない面が多い

>>881
カトラーが作ったわけじゃないんだけどね。若い人かな？

Windows API には、sjis/unicode 用の2つの関数がある。
すべて2種類作られている

MFC では、_T( )マクロで文字列を囲むと、両方に対応できる。
_T( "日本語" )
この型を、TCHAR 型と言う

そして、ソースコードのビルド時に、どちらのエンコードを使うか、指定できる

どの道、sjis を使うのは、日本人だけ。
外人のアプリでバグるから、どうしようもない

unicode なら外人も使うから、バグらない

外人が適当な実装するからバグりまくってた印象しかない
外人＜Unicode対応したぜ！he he（ASCII相当な英数字しか通らない）