[過去ﾛｸﾞ] 【Bash】Windows Subsystem for Linux【WSL】4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
835: 2019/02/28(木)12:05 ID:tUjvxMfH(1) AAS
>>833
日本語ファイル扱えねーだろ
836: 2019/02/28(木)14:12 ID:L+/5t2Z7(4/5) AAS
扱えるけど？扱えないものの名前言ってみ
837(1): 2019/02/28(木)18:42 ID:jXbhkhqb(1) AAS
𡈽𡌛𡑮𡢽𠮟.txt
838(1): 2019/02/28(木)21:16 ID:L+/5t2Z7(5/5) AAS
>>837
普通にメモ帳でそのファイル名で保存できた
っていうかそれ、日本語ファイル名じゃないしｗ
839(1): 2019/02/28(木)21:54 ID:SCNz79Se(1) AAS
ローマ字だってちゃんとした日本語ですよ？
840: 605 2019/02/28(木)22:34 ID:V5kpWLNn(1) AAS
>>831
それ、聞いたことある。自分ではkshをうまく扱えなくて、つかってない。
841: 2019/03/01(金)06:27 ID:kJeSfDT7(1) AAS
>>839
837のどこら辺がローマ字なの？
842(1): 2019/03/01(金)11:10 ID:O9KnEWE/(1) AAS
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にして解決するのもありかもしれない。
843(2): 2019/03/01(金)15:53 ID:jkxzyZN9(1) AAS
>>838
ファイル名はOSの管轄だからメモ帳とは関係ないだろ
NTFSのファイル名はそもそもUTF16が仕様だし
NT3.1でも対応したフォントさえあれば可能
844(1): 2019/03/01(金)17:13 ID:cp/SMV8Z(1/5) AAS
>>843
batはロケール依存。今もUnicodeでファイル名を渡せない仕様。
845: 2019/03/01(金)17:21 ID:dS+D8oye(1) AAS
>>842
Dynamic MemoryなんてWindowsゲストでもうんこでや(ﾎﾞｿ
846(2): 2019/03/01(金)19:02 ID:Qb5Iweg/(1) AAS
>>843
カーネル回りはUnicode前提で作られているけど
上部はWin9xとの互換性のためにShiftJISを採用
W系文字列とA系文字列を変換しつつ動いてる。
VC8.0からワイド文字がデフォルトに変更された。が・・・
未だにマルチバイトでビルドされたソフトも存在する。
847: 2019/03/01(金)19:20 ID:yAOTadDR(1) AAS
それがOSの機能・仕様となんの関係が
848: 2019/03/01(金)20:46 ID:+jAw0umc(1) AAS
AA省
849(2): 2019/03/01(金)20:51 ID:eEXh6B3P(1/3) AAS
>>844
> batはロケール依存。今もUnicodeでファイル名を渡せない仕様。
それはお前がコマンドプロンプトをsjisで起動してるからだろ
chcpでコードページを切り替えろよ
850: 2019/03/01(金)20:52 ID:eEXh6B3P(2/3) AAS
>>846
> カーネル回りはUnicode前提で作られているけど
> 上部はWin9xとの互換性のためにShiftJISを採用
上部ってなに？ Windowsと関係ない
一部のアプリがSJISを使っているからって、
WindowsはUnicodeなんだけど
851: 2019/03/01(金)21:35 ID:cp/SMV8Z(2/5) AAS
>>849
マルチバイトでビルドされたソフトには異なるロケールで引数渡しできない。文字化けする。>>846 さんの言ってることが現実。
Windows向けPerlディストリビューションのStrawberry Perlもマルチバイトでビルドされたソフトのひとつだよ。
852(1): 2019/03/01(金)21:53 ID:eEXh6B3P(3/3) AAS
だからアプリの問題ですよな。
OSと関係ない
853: 2019/03/01(金)22:09 ID:cp/SMV8Z(3/5) AAS
>>852
残念ながら、OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すのでアプリの問題じゃなくてOSの問題なのよ。
つまり chcp 65001 しててもアプリにはコードページ932の文字列が渡される。アプリ側ではどうしようもない。
854(1): 2019/03/01(金)22:14 ID:bitY+Vcd(1) AAS
> OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すので
ダウト。そんな事しない
855: 2019/03/01(金)22:26 ID:cp/SMV8Z(4/5) AAS
>>854
え？ほんまでっか！？
856: 2019/03/01(金)22:35 ID:xXgi/gLf(1/2) AAS
別に引数渡ししなくてもプロセス間で情報をやり取りする方法あるしな。
857: 2019/03/01(金)23:10 ID:0dHgJ/+e(1) AAS
chcpはファイル入出力のコードページには何も影響しないよ。
858: 2019/03/01(金)23:16 ID:xXgi/gLf(2/2) AAS
ファイル入出力？何言ってんだ？そんな話はしてねえぞ。
859: 2019/03/01(金)23:34 ID:3DxW6MgJ(1) AAS
OS（カーネル）はそんなことしない、引数の値をただ渡すだけ。そもそも、OSはどこにも噛んでない。
シェルの問題、パイプを噛ませるならともかく。
860: 2019/03/01(金)23:39 ID:cp/SMV8Z(5/5) AAS
Visual Studio でビルドしたバイナリだとmain()で始まるバイナリであっても、
GetCommandLineW() と CommandLineToArgvW()でオリジナルに近いコマンド引数をUTF-16で得ることはできるね。
861(1): 2019/03/02(土)06:36 ID:hgCaRIdz(1) AAS
>>849
実際に試しもしない馬鹿
862: 2019/03/02(土)07:43 ID:3tBpscIJ(1/10) AAS
>>861
何を試すか示されてないのに、
どうやって試せと？ｗ
お前なら何を試すんだ？
863(1): 2019/03/02(土)09:02 ID:wNBM8kkz(1) AAS
ここでのOSの機能ってのはNTkernel<各種サブシステムを含む＜コマンドラインを含む標準機能
って定義で揉めているの？
また文系が本質に関係ない所で暴れているのか
864: 2019/03/02(土)09:44 ID:DuLnb6JR(1) AAS
ファイル名の話をしてるかと思ったら突然batがどうこう言いだして次はAPIか
何がやりたいのやら
865(1): 2019/03/02(土)10:26 ID:LvykRUjv(1) AAS
カーネルがUnicodeでシェルがShiftJISだった
それだけ
866: 2019/03/02(土)10:41 ID:RR0lzZ2f(1/6) AAS
コマンドプロンプト自体は少しずつ進化していってる。
昔は表示できない非SJIS文字が多かった。単にchcpしただけでは対応できなかった。
867: 2019/03/02(土)11:57 ID:3tBpscIJ(2/10) AAS
>>863
そうじゃない。
OSはAPIを提供している。
その中には古いOSやアプリとの互換性を保つためのAPIもある。
その互換性を重視したAPIを使ったアプリの仕様は
アプリの問題でありOSの問題ではないということ
868: 2019/03/02(土)12:01 ID:3tBpscIJ(3/10) AAS
>>865
> カーネルがUnicodeでシェルがShiftJISだった
それだけだと中国でもShiftJISみたいだろｗ
それにシェルとコマンドプロンプトの違いもわかってない。
Windowsにおいてエクスプローラーもシェルだし、こっちは完全Unicode対応
Windows NT系は最初からUnicode。コマンドプロンプトもUnicode対応だが
互換性のためにデフォルトでは「Unicode対応でないプログラムの言語」の設定に
対応したコードページになっておりこれは変更できる。
ここまでかいて「それだけ」と言えるんだよ
869: 2019/03/02(土)12:06 ID:jIefrdBL(1) AAS
古いAPIをいまだに使ってるライブラリが存在するのが問題ってのは全然問題じゃない。
互換性は必要なのだからOSの問題でもない。アプリもメンテが大変だから対応でなくても仕方ない。
できないことをやろうとする利用者の問題だろ。
870(1): 2019/03/02(土)14:58 ID:iPk0eRVU(1) AAS
取り敢えずおまえらが重箱の隅をつついてヽ(ﾟ∀｡)ﾉｳｪ―ｲってやってるってだけはわかったわ
そんなに文句垂れるならVM使うなり、サブマシンをサーバー化してSSH/MOSH,RDPでつなぐなりすればいいだけ。
WSLは成長途中で成熟すらしてないのに文句垂れるのはアホ。MsWinだって温故知新の如く開発をしている。それでもIEやレガシーシステム捨てないような阿呆のために互換性を捏ね繰り回して考えている。
我々利用者は限られた選択肢をどうするかだけだろ
利用者として要求するならインサイダープログラムにでもさんかしてフィードバックでもしろ。そうじゃなきゃ知識ある人間が文句垂れんなよ。
871: 2019/03/02(土)16:42 ID:hG5hhj7h(1/3) AAS
>>870
そういう人どこにでもいるから気にしない。
WSLには本当に感謝してる人もいるってことを忘れないでね。
872(7): 2019/03/02(土)17:01 ID:G3h8Fg2L(1/2) AAS
sjis は、国際化されていない。
日本国内だけしか使えない
一方、UTF-8 は、すべての国(多国間)で使える
だから外人は、sjis 対応では作っていないから、ほとんどのアプリでバグる。
漏れら日本人が、言語一覧表に表示される、何百もの言語に対応しないのと同じ
ただ、WSL がすごいのは、Windows側のsjis のファイル名を、
Linux側では、UTF-8 に自動的に変換して、読めるようにしている
873: 2019/03/02(土)17:08 ID:RR0lzZ2f(2/6) AAS
>>872
逆。Unicodeのファイル名を可能な限りsjisで読めるように擬態してきたのがWindows NTのすごさ。
874(1): 2019/03/02(土)17:13 ID:xq/X7dI2(1) AAS
どっちでもよい。
単純にWindowsの開発が凄いってことだ
875(1): 2019/03/02(土)17:29 ID:f83cKfiP(1/2) AAS
Windows界隈でUnicodeというとUTF-16を指す、よね？
MSがすべての文字は16bitで固定的に表現できるって言ってた気がする
876(1): 2019/03/02(土)17:38 ID:RR0lzZ2f(3/6) AAS
UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。
SJISの並び順を維持したままソートするのがWindowsNTの地味な偉さでそ。
877: 2019/03/02(土)18:18 ID:pBLQHhxf(1) AAS
ソートしてるのはOSではなくてアプリでしょ？
878: 2019/03/02(土)18:23 ID:RR0lzZ2f(4/6) AAS
厳密にはアプリがソートする時に使うSJIS互換の比較関数をWindowsNTが提供している。もちろんアプリはそれを使う義務はないけど。
879: 2019/03/02(土)18:23 ID:uciZqlqG(1) AAS
アプリもAPIもOSの一部の機能を使ってるからOSが基本だな。
リストビューとかソートするプログラムもソート順だけ指定してあとはOSにお任せ。
880: 2019/03/02(土)19:00 ID:hG5hhj7h(2/3) AAS
>>874
ほんとそうですね。Linuxの10年先行ってる。
881(1): 2019/03/02(土)19:11 ID:BtrOpgTJ(1) AAS
Windowsではなく、WindowsNTを作ったカトラー(DEC出身)がすごいのだ
むしろWindows1.0〜Meとの互換のためにNTの潜在能力を出し切れていない面が多い
882: 2019/03/02(土)19:13 ID:hG5hhj7h(3/3) AAS
>>881
カトラーが作ったわけじゃないんだけどね。若い人かな？
883(1): 872 2019/03/02(土)19:33 ID:G3h8Fg2L(2/2) AAS
Windows API には、sjis/unicode 用の2つの関数がある。
すべて2種類作られている
MFC では、_T( )マクロで文字列を囲むと、両方に対応できる。
_T( "日本語" )
この型を、TCHAR 型と言う
そして、ソースコードのビルド時に、どちらのエンコードを使うか、指定できる
どの道、sjis を使うのは、日本人だけ。
外人のアプリでバグるから、どうしようもない
unicode なら外人も使うから、バグらない
884(1): 2019/03/02(土)20:08 ID:f83cKfiP(2/2) AAS
外人が適当な実装するからバグりまくってた印象しかない
外人＜Unicode対応したぜ！he he（ASCII相当な英数字しか通らない）
885: 2019/03/02(土)21:38 ID:YczcBIc8(1/2) AAS
>>872
Windows-31JはIANAにも登録されてると思うのだが
886: 2019/03/02(土)22:22 ID:RR0lzZ2f(5/6) AAS
ま、なんというか、WSLは織田政権が甲州征伐を決断したような「ついに来た」感はあるよね。
887(1): 2019/03/02(土)22:33 ID:3tBpscIJ(4/10) AAS
>>872
> ただ、WSL がすごいのは、Windows側のsjis のファイル名を、
Windows側にsjis のファイル名なんて一つもないよ。
すべてUnicodeのファイル名になってる。
888: 2019/03/02(土)22:34 ID:3tBpscIJ(5/10) AAS
>>883
> Windows API には、sjis/unicode 用の2つの関数がある。
あははｗ SJISは日本語専用なのに
日本語専用のAPIがあるわけないじゃないですかｗ
こういうレベルだから馬鹿にされるんやで
889: 2019/03/02(土)22:35 ID:3tBpscIJ(6/10) AAS
>>875
> MSがすべての文字は16bitで固定的に表現できるって言ってた気がする
MSは言っていない。言っていたのはUnicodeを作ってる連中
890(1): 2019/03/02(土)22:37 ID:3tBpscIJ(7/10) AAS
>>876
> UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。
ほんと言ってることのレベルが低すぎて哀れ
文字の並び？ Unicodeでは文字の並びは文字コードの並びではない。
Unicodeではどういう順番にするかという並べ方が複数定義されてる
現在のロケールに合わせて適切な順番を選んでいるだけ
891: 2019/03/02(土)22:41 ID:3tBpscIJ(8/10) AAS
>>872
今はもうsjisなんか使ってない
Unicodeを使って開発している。
外国人もUnicodeを使っている。そうしないと絵文字すら使えないから。
逆に言えば絵文字が使えればUnicode対応
Unicode対応で作ってるからほとんどのアプリはバグらない
892(1): 2019/03/02(土)23:07 ID:RR0lzZ2f(6/6) AAS
>>890
時系列がめちゃくちゃ
893(1): 2019/03/02(土)23:10 ID:3tBpscIJ(9/10) AAS
>>892
時系列？
Unicodeが最初にできて（文字の並びも）
Windows NTがUnicodeを採用して
その後にUTF-8が作られた
これでいい？
何がメチャクチャなのか知らんが
894: 2019/03/02(土)23:32 ID:YczcBIc8(2/2) AAS
>>887
FDの中も？
895: 2019/03/02(土)23:33 ID:3tBpscIJ(10/10) AAS
FDってなんですか？
896: 2019/03/03(日)02:58 ID:u6YJKUfs(1) AAS
FDもVFATにunicodeで入れてんじゃなかったか
897: 2019/03/03(日)03:40 ID:sxLmg3yE(1) AAS
>>893
最初が間違いだな
元々UnicodeはJStarのコードだよ
Etehernet（イエローケーブル）とか
長い間、画面解像度が1/72inchだったのもそうだ
898(1): 2019/03/03(日)08:32 ID:FmObGCcg(1/4) AAS
>>884
英語圏はデータ増えるの嫌って
A系関数I決め打ちで作ってるソフトが多かった気がするけどなあ
そもそも9x全盛期だったが
899: 2019/03/03(日)08:33 ID:FmObGCcg(2/4) AAS
W系がデフォになったのもVS2005のVCからだし
900: 2019/03/03(日)08:41 ID:FmObGCcg(3/4) AAS
TCHAR使って_UNICODEフラグ立てても
外人がchar感覚で配列いじくってるプログラムは多バイト圏でバグるよ
901(2): 2019/03/03(日)08:46 ID:tUxcdoMS(1) AAS
外部ﾘﾝｸ[aspx]:web.archive.org
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 の名称でドキュメント化されています。
ただしこれは実際の関数の名前ではなく、マクロ名です。
902: 2019/03/03(日)13:14 ID:UGPBP+FA(1/6) AAS
>>898
>>901にも書いてあるけど、普通はA系決め打ちのコードなんて書かないよ
コードには SetWindowText と書いておいて
シンボル UNICODE が定義されているかどうかで切り替える
903(1): 2019/03/03(日)13:34 ID:1pyMh31m(1) AAS
UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった
結果的にマクロで切り替えは無駄に複雑にしただけだった
904(1): 2019/03/03(日)13:42 ID:F/LPV+rw(1/4) AAS
Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。
905(1): 2019/03/03(日)13:48 ID:FmObGCcg(4/4) AAS
関数名はAもWも書いてない
UNICODEを定義せずに
文字型はchar
これはA決め打ちと言ってもいい
906: 2019/03/03(日)13:55 ID:UGPBP+FA(2/6) AAS
>>903
> UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
> きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった
なんで両方に対応しなきゃいけなんだ？
Unicodeバージョンだけ作ればいいんだよ。
907: 2019/03/03(日)13:56 ID:UGPBP+FA(3/6) AAS
>>904
> Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。
標準的なライブラリはすべてUnicode対応
サードパーティの古いライブラリなんか知らんわｗ
そのライブラリの問題だろ。
908: 2019/03/03(日)13:57 ID:UGPBP+FA(4/6) AAS
>>905
シンボルUNICODEを定義していなければ、A決め打ち
シンボルUNICODEを定義していれば、W決め打ち
通常はシンボルUNICODEを定義するので、W決め打ち
わかった？
909: 2019/03/03(日)15:43 ID:QnjPbk4c(1/4) AAS
linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。
なぜかというとVisual StudioでUTF-16に相当するwchar_tの型サイズや使い道が、他のコンパイラでは異なるから。
多くの人が使っている64bit版WSLのgccは既定でwchar_tがUTF-32なのは周知の事実でしょうに。
試しにWSLのgccでsizeof(wchar_t)を出力するプログラムを書いてみればすぐわかる。
910: 2019/03/03(日)16:11 ID:9h6OtHDD(1/2) AAS
まあ全部TCHAR系にしてun*x側で標準の(ワイドじゃない)文字列関数に展開するマクロを用意しとけば一応可能だけど
全体的にコードがキモくなるからやってるのはあんま見ないね
だいたいwmain用意しといて引数はさっさとUTF-8に変換して内部はchar*オンリーで
Windows依存のところでwchar*に戻すみたいなコードを入れてる気がする
ただそれもCJK圏の人が気を利かせてパッチ投げて追加されるなんて場合が多い感じだけど
911: 2019/03/03(日)16:21 ID:UGPBP+FA(5/6) AAS
> linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。
だからマクロがあるんだろ。何を言ってるんだろうか？
もしかしてマクロの意味わかってない？
シンボルUNICODEで簡単に切り替えられるんだよ？
912: 2019/03/03(日)16:26 ID:UGPBP+FA(6/6) AAS
というか、そもそも言ってることがめちゃくちゃで、
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を使うのが正しい。
な？言ってることメチャクチャだろ？
こいつわかってないんだよ。
913: 2019/03/03(日)16:45 ID:F/LPV+rw(2/4) AAS
やっぱり、日本が悪いニダ！
914(1): 2019/03/03(日)17:21 ID:QnjPbk4c(2/4) AAS
文字列に対する処理は、UTF8よりもUTF-16/32の方がコードを簡潔に書ける利点があるよ。
メモリ上はUTF-16/32、プロセス間のデータやりとりはUTF-8、という使い分けがさらに進んでいく気がする。
915: 2019/03/03(日)17:31 ID:9h6OtHDD(2/2) AAS
サロゲートペアとか考えるともうUTF-16はいらない子だと思うんですけど！
916: 2019/03/03(日)18:29 ID:pYe6Luxl(1) AAS
いつまで脱線続けるんだ？
917(1): 2019/03/03(日)19:51 ID:NJPd5Ggk(1/2) AAS
>>914
文字に対する処理はライブラリを使わないとやってられないんだから
もうそんなレベルじゃない。逆にライブラリ使えばどっちでもいい。
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
外部ﾘﾝｸ:tech.nikkeibp.co.jp
> 最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、
> 漢字1文字は必ずしも4バイト以内に収まらない。UTF-8でもUTF-16でも、
> 最悪8バイトは必要になると考えられる。
918: 2019/03/03(日)20:42 ID:QnjPbk4c(3/4) AAS
>>917
確かにそのとおり。一文字を固定長と決めつけたコードを書くこと自体が良くない。
将来、人類は知能の高い地球外生命体と遭遇してさらに文字が増える可能性もある。
919: 2019/03/03(日)20:55 ID:NJPd5Ggk(2/2) AAS
知能の高い地球外生命体と遭遇したら、
その知能の高い地球外生命体が使ってる文字コードを使えばいい。
宇宙コード、universe code、通称 unicode
920: 2019/03/03(日)21:10 ID:QnjPbk4c(4/4) AAS
知能の高い地球外生命体が使ってる文字コードがしれっとロケールのひとつとしてとりこまれる悪夢に10000ペリカ
921: 2019/03/03(日)22:01 ID:6s9AlSZU(1/2) AAS
知能の高い地球外生命体はchar=int=256bitとか使ってそうだがなあ
922: 872 2019/03/03(日)22:36 ID:ePOPdei3(1/2) AAS
>>901
まさにこれ！
Unicode は多国間で共通だけど、ANSI は各国で異なる。
ANSI は日本では、sjis になる
外人は、sjis を知らないし、
逆に日本人は、sjis 以外の他国の文字コードを知らない
外人は半角英数字で考えるから、char 配列で、1バイトずついじってくるから、
複数バイトで構成される文字で、バグる
923: 872 2019/03/03(日)22:50 ID:ePOPdei3(2/2) AAS
例えば、paiza.IO のサイトで、ブラウザからプログラミングしても、
日本語を入力すると、カーソル移動がおかしくなる。
日本語文字のバイト数分(3バイト？)、移動してしまう
外人には、こういうプログラミングが多い
また、Windows のRuby(MSYS2)で、irb で日本語があるとバグるけど、
WSLのRubyでは、バグらない！
これは、WSLでは、コマンドプロンプトと同じ画面を使っているから。
Windowsのコマンドプロンプト/PowerShell は、日本語でもバグらない
924(1): 2019/03/03(日)23:06 ID:MtblX4Xf(1) AAS
日本語を使う人がフィードバックしてないだけだと思うけど
コンソールアプリの日本語が化けるのはプレビューで去年踏んだが…
925: 2019/03/03(日)23:18 ID:F/LPV+rw(3/4) AAS
Cloud9だったら問題ないけどな・・・
プログラム書いてるやつのせいというより、処理系の問題かな。
926(1): 2019/03/03(日)23:26 ID:6s9AlSZU(2/2) AAS
>>924
まだ治ってないよね、これ
927: 2019/03/03(日)23:58 ID:F/LPV+rw(4/4) AAS
そんなに嫌ならお前らがフィードバックしろw
928(1): 2019/03/04(月)00:00 ID:/WEAn4u6(1) AAS
コマンドプロンプトで半角/全角を切り替えて入力しているとキーカーソルが表示されなくなる不具合がたまに起きるね。
コマンドプロンプトは地味に進歩しつつバグも生まれていっている。
929: 2019/03/04(月)00:06 ID:iMeu/Dim(1) AAS
>>926
多分別件かな
踏んだのは日本語の表示が化けるってヤツだった
ファイルにリダイレクトすると大丈夫
もちろんフィードバック済み、コレクションにされたけど200票以上入ってた
930(1): 2019/03/04(月)10:38 ID:z8l/1Wf8(1) AAS
ゔぁー、荒れてるな。
上の方でX入れんと日本語扱えないじゃんって書いたのは俺だが、
単に標準のbashターミナルでは日本語入力できないじゃんってという純粋にWSL環境の話だったのに…
931: 2019/03/04(月)10:48 ID:q38WbcYi(1) AAS
このスレ数人スレチおじさんが常駐してるよな
932(1): 2019/03/04(月)11:05 ID:zBAP+DEh(1) AAS
>>930
標準のbashターミナルで日本語入力できるから、
どっかの馬鹿が勘違いしただけという話で終わってる
933: 2019/03/04(月)19:38 ID:tJIpndqu(1) AAS
>>932
コンソールはwindowsのimeで日本語入力可能。vim, emacsコンソール版, nano
などで使える。
wslttyでも使える。
GUIはMozcなどで入力。
ubuntuなら、後者もググれば、情報あり。
934: 2019/03/04(月)23:45 ID:0O5iFNQk(1) AAS
>>928
それでカーソルが消えるのか
上下前次1-新書関写板覧索設栞歴
あと 68 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.019s