【PC】マイクロソフト、Windows 10にUNIX系OSと似た擬似コンソール実装
■ このスレッドは過去ログ倉庫に格納されています
長い間、Windowsにはネイティブに動作するOpenSSHの実装が存在しない状況が続いてきた。コンソールアプリケーションもかなりトリッキーな実装を行っている。UNIX系オペレーティングシステムでは当たり前に実現できていることが、Windowsでは実現されてこなかった。 Windowsでも結果的に同じように見える振る舞いを実現できるが、UNIX系のオペレーティングが提供している仕組みとあまりに違いすぎるため、これまでUNIX系オペレーティングで提供されてきたコンソールに関連するコマンドの移植は進んでこなかった。しかし、2018年秋のWinodws 10アップデートでこの状況が大きく変わる可能性がある。 Microsoftは現在開発を進めているWindows 10に「擬似端末(Pseudo Console)」の機能を実装するようだ。実装する機能の詳細は「Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY) - Windows Command Line Tools For Developers」にまとまっている。 UNIX系オペレーティングで実装されている仕組みとよく似ており、こうした機能を利用しているコマンドの移植がこれまでと比べて格段に簡単になるものと見られる。開発者は注目しておきたい機能だ。 物理的ターミナルはキー入力の受け取りや入力されたデータのバッファリングと送信、逆に送られてくるメッセージの処理と表示といった処理を行っている。マシンの性能が向上し、マルチウィンドウシステム上で複数のターミナルアプリケーションを実行できるようになると、これまで物理ターミナルが実施していた処理をソフトウェア的に行う必要性がでてきた。この時に開発された仕組みが擬似端末だ。物理ターミナルが行っていたような処理を擬似端末が担う。 擬似端末はsshでサーバにログインする場合などにも使われている。現在であれば、sshでサーバにログインすればその分だけ/dev/pts/にファイルが生えてくることを確認できるだろう。sshでログインするとその分だけ擬似端末が使われている。こうした仕組みがあることで、ターミナルを利用するコマンドを簡単に開発できるようになっている。 これまでのWindowには擬似端末の仕組みが用意されていなかったため、Windows版のOpenSSHは以下の画面のようにWindowsで提供されている機能を使って動作を実現していた。オリジナルのOpenSSHの実装系と比べると、Windows風のコードを従来の実装に交ぜることになる。 https://news.mynavi.jp/article/20180817-679662/ >>94 >>98 コマンドプロンプトで、chcp 65001 でできるだろ。 そんなことも知らんのか? >>102 デフォルトでって話だろ 自分のPCだけ換えても意味無いからな >>57 macOSはBSD系UNIXがベースだ ことさら売りにしていない とにかくShift_JISは辞めろ MSさえ撤廃すれば日本人の目が覚める あと、UTF-8のBOM付き辞めろ 狂人はなぜかやたら「UTF-8のBOM」を攻撃するという話がまた裏付けられた。 >>110 そもそもUTF-8にBOMなど必要ない UTF-8にバイトオーダーなど無いから Excelの.csvファイルなんかでいまだにBOM付き必須になっている意固地さはなんだろね MSはLinux文化も認めて両対応を進めているんだから、他のOSでも対応を強化すればいいだけ >>111 U+FEFFは単にバイトオーダーを示すためだけのものじゃあないから。 UTF-8にバイト順は関係ないが、RFC等で言うところのBOM(U+FEFF)に意味はある。 >>104 レジストリ設定で、コマンドプロンプトのコードページ初期値は、ユーザーアカウント 毎に変えられる。 さらに言えば、コンソールアプリ内からも、SetThreadLocale() というAPIで変えられるし、関数名から判るとおり、スレッド毎に変えられる。 ttps://msdn.microsoft.com/ja-jp/library/cc448087.aspx そんなことも知らないの? 最近追加された新しいAPIではなく、XPよりも前の Windows NT 3.51から実装されている。 日本語版がShift JIS(CP932)なのは、過去のソフトウェア資産の互換性を保つため。 >>94 既にベータ版機能として利用可能だろ だが有効にすると結構なアプリが誤動作する Windowsの性で、過去のソフトウェア資産が殆ど死にそうになってる >>117 だから何? ディフォルトの意味わかってないのか? w >>120 BOMの件も同様だけど、決め打ちでしかソフトウェアを組めない馬鹿は死ね。 そういうこと。 >>121 こんな所で喚いてないでソフトメーカーに言えよ、バーカ 多分身内の誰かへの当てこすりなんだろう 察してやろう >>117 寝言は世の中に溢れるShift-JIS文書を全部レジストリ設定wでUTF-8に変換してから言えw お前のPCのローカル環境の話はチラシの裏にでも書いてろ池沼 >>116 あんたそりゃUTF-16のBOMでしょ >>126 ファイル先頭のFEFFかFFFEの2バイトでUTF-16文字コードのバイトオーダーを指定するんだよ FEFFならビッグエンディアン UTF-8 0xEF 0xBB 0xBF UTF-16 BE 0xFE 0xFF LE 0xFF 0xFE >>127 まさかと思ったが U+FEFF という表記がバイト列じゃなくてコードポイントを表しているという 基礎知識すらないんじゃ話にならん。Unicodeについて語る資格なし。 UnicodeがはじまったころはアメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISやEUC-JPが 主流であり、使用されている符号化方式がUnicodeであることを明確に区別する必要があった。その方法として、 先頭のデータにテキスト以外のデータを入れることが発案された。 また、1文字が数バイトに渡るUnicodeでは、エンディアンの違いが認識できないと、例えばPowerPC Macintoshと x86 MS-DOSとの間で正常にデータの交換ができないため、この先頭バイトにより区別できるようにされた。 >>131 生半可な知識ですね。 コードポイントって単なるコード表の中の文字位置のことですよ。 BOMの必要性とは関係ない話。 そもそもあなた>>116 でBOM(U+FEFF)って書いているじゃないですか なんか生かじりで人にからんでいますねえ 通信ならバイトオーダーを調整出来るだろうけど ファイル共有やってたらどうしようもないな >>17 大型アップデートはHDDだと3〜4時間は平気でかかる SSDでも1時間は必要 >>135 4月の大型アップデート30分も掛かんなかったけど、どんだけオンボロPC使ってるの? まあ、初期の頃は結構ひどかったけど、年々短くなってきてる印象だけどね ただ、累積Updateを積み上げたときは酷い 実家にあるPC、ほとんど触られてないからか帰省のたびに山のようなアップデートが来ててうざかったから そちらはCloudReadyに置き換えた >>133 流石にこれは恥ずかしい Unicodeスカラ値 とか知らんのかよ w きっとコードポイント知らなかったんだろうな とりあえずググってみたがMuT7wP7Tの言ってることは理解できなかったみたいなw >>140 エミュレータ使わずにできるようになるからいいよねっていうスレなんだよ エミュレータだと出来たことが出来なくなったりは、しない? >>105 >>107 なんも反論できない人が書くような常套手段のようなレス て思ったら>>133 で、まあそういう人なのねと納得w >>136 オンボロ?i5の6300Uだけど スペックは高い方だ >>144 なんでCPUを真っ先に出すの ストレージとメモリについて出す方が適切だろうに 以前からコンソールあったでしょ config.sysとかタイプするやつ >>138 >>139 何言ってるのかなぁ、この人たち UTF-8でBOMが必要か否かの話を表記方法の話にすり替えている 最初に絡んだID:MuT7wP7T君はどこへ逃げたのでしょうか? ID:Zt3S6RPU君と同じ匂いしますけど コードポイントだとかUnicodeスカラー値とかってさも自慢げにタームだけ振り回しているけど、それがBOMの必要性と何の関係があるのかという言及が一切ありませんね。 ボクは逃げも隠れもしないよ ID:TaAA6koY=ID:P88+4vq6 だからね >>116 ↑ これ書いた人、きちんと落とし前付けてね UTF-8のBOMの話にUTF-16のBOM表記(ビッグエンディアン)持ち出して、「RFC等で言うところの」などと頓珍漢過ぎてわからんのですわ。 >>148 必要か否かの話なんてしてない BOM(U+FEFF)に > あんたそりゃUTF-16のBOMでしょ とか言うアホを嘲笑してるだけ w >>151 >必要か否かの話なんてしてない >>116 の意味は? それと >>125 のどこがおかしいのか指摘して欲しい >>57 Mac は互換じゃない Unixそのもの しかもNeXTSTEP譲りのGUIで完璧 >>152 > U+FEFFは単にバイトオーダーを示すためだけのものじゃあないから。 → >>130 , >>132 の前半 > >>125 のどこがおかしいのか指摘して欲しい → U+FEFFはコードポイントの表記でUTF-8にもあるからU+FEFFを見てUTF-16と思いこむのは知識が足りなさ過ぎ ちなみにU+FEFFのバイト列がどうなるかは>>129 が書いてる >>152 とりあえず落ち着いて皆のレスを声に出して100回読んでから出直せゆとり >>145 ストレージはSSDって最初に書いただろ オンボロとか的外れな指摘にはCPU出せばそれで十分 別に君にトラブル解決してもらうために質問してるわけでもなし Embedded化したXpのAM1マシンですら1時間も掛からん。 トラブルシュートすらできん無能は、なんでもWindowsのせいか。おめでてぇな。 >>156 空きはどれだけあるのか、PCIe接続なのか、そもそもメモリの容量と帯域はなんなのか 全くといっていいほどレスから分からないから、なにもしようがない アスペなの君 わからないならスルー 5チャンネルからのお願いです ubuntuの上でWindowsを動かせはいいのではないか? >>160 MS-DOS上でWindowsを動かしたようにか? コマンドラインはCygwin使ってるな コマンドプロンプトはUTF-8に対応してないからな 今はもう、テキストファイルはよほどの理由がない限りUTF-8にしてる >>154 君は>>129 の意味わかってないでしょ? ちょっと気の毒な感じがする。 >>154 >U+FEFFはコードポイントの表記でUTF-8にもあるから テキストとバイナリの区別ついているか? 大丈夫? >>163 > 君は>>129 の意味わかってないでしょ? なら説明してみ > ちょっと気の毒な感じがする。 お前さんがな w >>164 > テキストとバイナリの区別ついているか? テキスト? 頭大丈夫? >>165 >なら説明してみ BOM付きUTF-8ならファイル先頭から3バイトがEF,BB,BF UTF-16ならファイル先頭から2バイトがFE,FFもしくはFF,FE。前者ならビックエンディアン、後者ならリトルエンディアン わかった? 君はスクリプト言語しか経験ないのかな? >>165 ターミナルでUTF-8(BOM付)とUFT-16エンコーディングのファイルを16進ダンプしてみ C:\Users\user>filedump utf16L.txt -------- 0 1 2 3 4 5 6 7 8 9 a b c d e f 3 7 b f 00000000 : fffe226f 575b0d00 0a00 .."oW[.... C:\Users\user>filedump utf16B.txt -------- 0 1 2 3 4 5 6 7 8 9 a b c d e f 3 7 b f 00000000 : feff6f22 5b57000d 000a ..o"[W.... C:\Users\user>type utf16L.txt 漢字 C:\Users\user>type utf16B.txt o"[W >>166-167 > BOM付きUTF-8ならファイル先頭から3バイトがEF,BB,BF > UTF-16ならファイル先頭から2バイトがFE,FFもしくはFF,FE。前者ならビックエンディアン、後者ならリトルエンディアン それ… >> ちなみにU+FEFFのバイト列がどうなるかは>>129 が書いてる で書かれてるバイト列のことなんだけど… で、テキストってどこから出てきたんだ? w 先頭2バイトのコードは、テキストデータでは使われない値 すでにubuntuとかsuseのbash入れられるのになんで? >>158 中途半端に知識のある典型的なコミュ障オタクだね、君 だから君にどうにかしてもらおうとなん思ってないから、そんな情報はいらんのだよ 大体、SATAだろうがNVMeだろうが、メモリ帯域幅がどうであろうが、 ことWindows updateにおいてはそんなもんの影響は大したことは無い 僕ちゃんのハイスペマシンだと30分かからず終わるのかもしれないが、 激安でもない普通に売ってる現行機でも、大型アップデートには相当の時間がかかるもの 所要時間なんてググればスペックと一緒にいくらでも出てくるわ U+FEFFがBOMのコードポイントだってことは理解できたのかな?w 今更 アップルの通って着た路線を真似するなよ。 最低。 >>172 多分、アフィとかでネットDE真実をしてしまってるんだろうが マウスとケース込みで20万もしないノートの無線でも1時間なんてとてもかからなかったんだが えーと、君のハイスペって何? >>172 これほどみっともない逃げのレスも珍しい そうそう 僕ちゃんは30分も掛からないよー アップデートに時間がかかるって言ってる奴はみんなポンコツ使ってるんだよーって思ってな 君の世界ではそうなんだからそれでいいんじゃないか >>164 はつまり、U+FEFFが文字を表している(コードポイント)ということがどうしても理解できないんだろうな。 今までのレスを見るに彼の頭の中には具体的な「文字コード」しか存在しない。 >>181 いやだからさ、外を知るもなにも(てかソースがネットのみじゃないならむしろ俺みたいに思うが) 国産メーカーの低性能ぼったPC強制的に使わされてんならまあそうだろねて同意できるけどさ SSD、接続規格、メモリ関係ない!とかはちょっと頭可笑しいんじゃね?と思うからさ ちなどこのメーカーのなんてPCよ? 自作なら構成どうぞ >>183 1時間からいつのまにか30分に急に変わってて草 あーやっぱりネットDE真実してた人でしたか(笑) 149 名刺は切らしておりまして 2018/08/20(月) 06:48:33.40 ID:P88+4vq6 ボクは逃げも隠れもしないよ ID:TaAA6koY=ID:P88+4vq6 だからね >>185 SSDでもSATAとnvmeでアップデートに大きな差が出ると思ってる時点で、 レベルがわかったからもういいよ >>186 意味がわからんな。 30分掛からないっていってるのはポンコツ君だけどね アップデートは概ね30分以内に終わってる それに掛かる時間が遅いと感じたことはない インストールしているソフトウェアが多いと それとの整合性取りながら更新情報を作成しているんじゃないのか? ちなみにネットde真実って言葉が大好きみたいだが、 システム部門の人間なんで、その言葉とは対極にいるかな 検索すれば、他人の書いた実例が出てくるから言ったまで 擬似コンソールのスレなのになんでBOMとかWindows Updateで延々とレスバトルしてんのw 凡人は テーマがよく分からないときに 自分が分かる話題を話したがる 疑似コンソールのはなし、続けてくれ給えw >>190 とはいえCドライブにOS除いて100GB以上はいってるのでも1時間もかかったことない 他の人らもだいたい似たようなもん、35〜50分程度 たしかに昔のノートなら4時間ほどかかったがな 3600rpmのHDDだわ、メモリ4GBだわで、もうね >>191 いや外に出てみろとか頓珍漢なこと書いてたので、売り言葉に買い言葉でw ちなみにそっちはネット記事しかソースないのね、ほんとにネットDE真実じゃんw 周りの人に聞いてみたら? >>175 だから何? それがBOM無しUTF-8ファイルの先頭にきたら心配だとでもW >>116 と>>164 の落とし前つけてね なにを心配しているのか全然わからないわけだわ >>184 >具体的な「文字コード」しか存在しない。 いや、ファイル中のバイトのシーケンスだ >>175 >>184 実際UTF-8(BOM付)文字列として書き込むときはエスケープして "\uFEFF" のようにするでしょ。 そうすればバイトシーケンスはEF,BB,BFになるわけ >>125 U+FEFFはUTF-16の文字コードじゃないってことくらいらは理解できたか?www UnicodeにBOMは必須だろ BOMの概念がないEUCJPやらSJISと見分けがつかないじゃん 特にSJISとは見分けがつきづらい 先にJISコード規格があってそれを元にしてんだから後続はきちんと配慮すべき >>195 覚えたての言葉を使いたくてしょうがないって感じだな。 ネット上の情報はみんな根拠に欠ける扱いか 大体、自分こそソースなんて何一つ出してないのに何を言ってるんだ? 俺は君と同じく実体験からものを言っていて、 それを補強するものとしてネット情報を上げてるだけだが ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる