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

>>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相当な英数字しか通らない）

>>872
Windows-31JはIANAにも登録されてると思うのだが

ま、なんというか、WSLは織田政権が甲州征伐を決断したような「ついに来た」感はあるよね。

>>872
> ただ、WSL がすごいのは、Windows側のsjis のファイル名を、

Windows側にsjis のファイル名なんて一つもないよ。
すべてUnicodeのファイル名になってる。

>>883
> Windows API には、sjis/unicode 用の2つの関数がある。

あははｗ SJISは日本語専用なのに
日本語専用のAPIがあるわけないじゃないですかｗ

こういうレベルだから馬鹿にされるんやで

>>875
> MSがすべての文字は16bitで固定的に表現できるって言ってた気がする
MSは言っていない。言っていたのはUnicodeを作ってる連中

>>876
> UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。

ほんと言ってることのレベルが低すぎて哀れ

文字の並び？ Unicodeでは文字の並びは文字コードの並びではない。
Unicodeではどういう順番にするかという並べ方が複数定義されてる
現在のロケールに合わせて適切な順番を選んでいるだけ

>>872
今はもうsjisなんか使ってない
Unicodeを使って開発している。

外国人もUnicodeを使っている。そうしないと絵文字すら使えないから。
逆に言えば絵文字が使えればUnicode対応

Unicode対応で作ってるからほとんどのアプリはバグらない

>>890
時系列がめちゃくちゃ

>>892
時系列？

Unicodeが最初にできて（文字の並びも）
Windows NTがUnicodeを採用して
その後にUTF-8が作られた

これでいい？
何がメチャクチャなのか知らんが

>>887
FDの中も？

FDってなんですか？

FDもVFATにunicodeで入れてんじゃなかったか

>>893
最初が間違いだな
元々UnicodeはJStarのコードだよ
Etehernet（イエローケーブル）とか
長い間、画面解像度が1/72inchだったのもそうだ

>>884

英語圏はデータ増えるの嫌って
A系関数I決め打ちで作ってるソフトが多かった気がするけどなあ

そもそも9x全盛期だったが

W系がデフォになったのもVS2005のVCからだし

TCHAR使って_UNICODEフラグ立てても
外人がchar感覚で配列いじくってるプログラムは多バイト圏でバグるよ

https://web.archive.org/web/20140606085036/http://msdn.microsoft.com/ja-jp/library/windows/desktop/ff381407(v=vs.85).aspx

Unicode 関数と ANSI 関数

マイクロソフトが Windows に Unicode のサポートを導入したときは、
スムーズな移行を実現するために ANSI 文字列と Unicode 文字列のそれぞれに対応する 2 つの API を提供しました。
たとえば、ウィンドウのタイトル バーのテキストを設定する関数には次の 2 つがあります。

SetWindowTextA: ANSI 文字列を使用します。
SetWindowTextW: Unicode 文字列を使用します。

内部的には、ANSI バージョンは文字列を Unicode に変換しています。
また、Windows ヘッダーが定義するマクロによって Unicode バージョンに変換できます。
ここではプリプロセッサ シンボル UNICODE が定義されていると Unicode になり、定義されていない場合は ANSI バージョンになります。

#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif

MSDN では、この関数は SetWindowText の名称でドキュメント化されています。
ただしこれは実際の関数の名前ではなく、マクロ名です。

>>898

>>901にも書いてあるけど、普通はA系決め打ちのコードなんて書かないよ
コードには SetWindowText と書いておいて
シンボル UNICODE が定義されているかどうかで切り替える

UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった
結果的にマクロで切り替えは無駄に複雑にしただけだった

Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。

関数名はAもWも書いてない
UNICODEを定義せずに
文字型はchar

これはA決め打ちと言ってもいい

>>903
> UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
> きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった

なんで両方に対応しなきゃいけなんだ？
Unicodeバージョンだけ作ればいいんだよ。

>>904
> Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。

標準的なライブラリはすべてUnicode対応

サードパーティの古いライブラリなんか知らんわｗ
そのライブラリの問題だろ。

>>905
シンボルUNICODEを定義していなければ、A決め打ち
シンボルUNICODEを定義していれば、W決め打ち

通常はシンボルUNICODEを定義するので、W決め打ち
わかった？

linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。
なぜかというとVisual StudioでUTF-16に相当するwchar_tの型サイズや使い道が、他のコンパイラでは異なるから。
多くの人が使っている64bit版WSLのgccは既定でwchar_tがUTF-32なのは周知の事実でしょうに。
試しにWSLのgccでsizeof(wchar_t)を出力するプログラムを書いてみればすぐわかる。

まあ全部TCHAR系にしてun*x側で標準の(ワイドじゃない)文字列関数に展開するマクロを用意しとけば一応可能だけど
全体的にコードがキモくなるからやってるのはあんま見ないね
だいたいwmain用意しといて引数はさっさとUTF-8に変換して内部はchar*オンリーで
Windows依存のところでwchar*に戻すみたいなコードを入れてる気がする
ただそれもCJK圏の人が気を利かせてパッチ投げて追加されるなんて場合が多い感じだけど

> linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。

だからマクロがあるんだろ。何を言ってるんだろうか？

もしかしてマクロの意味わかってない？
シンボルUNICODEで簡単に切り替えられるんだよ？

というか、そもそも言ってることがめちゃくちゃで、

AとかWというのはAPI呼び出しの話であって、
wchar_tとかには関係ない話。

> wchar_tがUTF-32なのは周知の事実でしょうに。
とかいうが、普通はLinuxではUTF-8を使うだろ？
おかしいよな？ちゃんと理由を説明できるかい？ｗ

UTF-8に変換して内部charというのなら、Windowsでも内部charで扱えばいいだけだし、
API呼び出しは話が別で、内部をUTF-8（char型）にしてるならAを使うのは間違っている。（実体はUTF-8だから）
この場合はUTF-8をUTF-16に変換してWを使うのが正しい。

な？言ってることメチャクチャだろ？
こいつわかってないんだよ。

やっぱり、日本が悪いニダ！

文字列に対する処理は、UTF8よりもUTF-16/32の方がコードを簡潔に書ける利点があるよ。
メモリ上はUTF-16/32、プロセス間のデータやりとりはUTF-8、という使い分けがさらに進んでいく気がする。

サロゲートペアとか考えるともうUTF-16はいらない子だと思うんですけど！

いつまで脱線続けるんだ？

>>914
文字に対する処理はライブラリを使わないとやってられないんだから
もうそんなレベルじゃない。逆にライブラリ使えばどっちでもいい。

漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/
> 最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、
> 漢字1文字は必ずしも4バイト以内に収まらない。UTF-8でもUTF-16でも、
> 最悪8バイトは必要になると考えられる。

>>917
確かにそのとおり。一文字を固定長と決めつけたコードを書くこと自体が良くない。
将来、人類は知能の高い地球外生命体と遭遇してさらに文字が増える可能性もある。

知能の高い地球外生命体と遭遇したら、
その知能の高い地球外生命体が使ってる文字コードを使えばいい。

宇宙コード、universe code、通称 unicode

知能の高い地球外生命体が使ってる文字コードがしれっとロケールのひとつとしてとりこまれる悪夢に10000ペリカ

知能の高い地球外生命体はchar=int=256bitとか使ってそうだがなあ

>>901
まさにこれ！

Unicode は多国間で共通だけど、ANSI は各国で異なる。
ANSI は日本では、sjis になる

外人は、sjis を知らないし、
逆に日本人は、sjis 以外の他国の文字コードを知らない

外人は半角英数字で考えるから、char 配列で、1バイトずついじってくるから、
複数バイトで構成される文字で、バグる

例えば、paiza.IO のサイトで、ブラウザからプログラミングしても、
日本語を入力すると、カーソル移動がおかしくなる。
日本語文字のバイト数分(3バイト？)、移動してしまう

外人には、こういうプログラミングが多い

また、Windows のRuby(MSYS2)で、irb で日本語があるとバグるけど、
WSLのRubyでは、バグらない！

これは、WSLでは、コマンドプロンプトと同じ画面を使っているから。
Windowsのコマンドプロンプト/PowerShell は、日本語でもバグらない

日本語を使う人がフィードバックしてないだけだと思うけど
コンソールアプリの日本語が化けるのはプレビューで去年踏んだが…

Cloud9だったら問題ないけどな・・・
プログラム書いてるやつのせいというより、処理系の問題かな。

>>924
まだ治ってないよね、これ

そんなに嫌ならお前らがフィードバックしろw

コマンドプロンプトで半角/全角を切り替えて入力しているとキーカーソルが表示されなくなる不具合がたまに起きるね。
コマンドプロンプトは地味に進歩しつつバグも生まれていっている。

>>926
多分別件かな
踏んだのは日本語の表示が化けるってヤツだった
ファイルにリダイレクトすると大丈夫

もちろんフィードバック済み、コレクションにされたけど200票以上入ってた

ゔぁー、荒れてるな。
上の方でX入れんと日本語扱えないじゃんって書いたのは俺だが、
単に標準のbashターミナルでは日本語入力できないじゃんってという純粋にWSL環境の話だったのに…

このスレ数人スレチおじさんが常駐してるよな

>>930
標準のbashターミナルで日本語入力できるから、
どっかの馬鹿が勘違いしただけという話で終わってる

>>932
コンソールはwindowsのimeで日本語入力可能。vim, emacsコンソール版, nano
などで使える。
wslttyでも使える。

GUIはMozcなどで入力。
ubuntuなら、後者もググれば、情報あり。

>>928
それでカーソルが消えるのか

ローカルでLAMP開発したいんですがwslでやるのと仮想マシンでやるのは大きく違いはありますか？
後、PCのスペックがCORE i3の4GBなんですが仮想マシンでやると重くて作業にならないみたいな事になりますか？

>>935
仮想マシンは固定でメモリを割り当てる必要があるから4GBだとかなり厳しい

4GBだとOSとブラウザだけで限界じゃないか？

サーバーだけなら1GBでもいける。
でも、Windows側でEclipseとかIDE立ち上げるときつそう。
PHPで開発するらしいし、Cloud9とかサーバーサイドで動くIDEを同じVMに作る手もあるけど・・・

WSLにこだわるなら、これやってみる？
https://qiita.com/naniwaKun/items/b7b45a6e6ed33ce81eb9

ctrl-iで補完したりlsするだけでファイル探しにめっちゃ固まるな。
やっぱ根本的にディスクアクセス遅い。

やはり4GBだと厳しんですねもうちょい良いやつ買えば良かった(-_-)ありがとうございます
cloud9ですか調べてみますねm(_ _)m

>>940
HDD?

正直言うと
それなら癖あってもラズパイ一台買ったほうがいい
それかもうPentium４とかでもいいからパソコン買ってそれに打ち込む
個人的おすすめはまだ現役でイケるcore2duoに4ギガ積んでxubuntuとかUbuntu Server, centosいれるほうがいい。

DB、開発環境はWindows。
PHP、Apacheはラズパイか？

ラズパイ3以降はUSBのバスパワーじゃ動かないから、ACアダプター追加の投資がいるな。
まあ、ケース含めて一万もかからないけど、無印やZeroは貧弱するからLAMP
に向かない。