【Bash】Windows Subsystem for Linux【Ubuntu】2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Windowsのテキストエディタで編集しても問題なくなったのかな? >>565
こんなことするぐらいだったら、Windowsも初めからUnixに載せ替えればいいと思う。 >>567
MSの目的はWindowsの世界はそのままに
Linuxを取り込むことだから、Unixに載せ替えただけじゃ実現不可能
Unixに載せ替えたら今度はUnix上でWindowsアプリが
動くようにしないといけない
Wineをのっとったとしてももっと時間がかかるよ
WSLがリリースされた後開発が続くか不安だったが杞憂だったようだ。
十分な速度で機能が追加されていっている Windows側にWSLの技術を持ち込むのはどうかな WSLでX Window Systemのサーバー側が作れない(難しい)理由が >>571 に書いてあった
> 3種類の環境サブシステムの中では、Windowsサブシステムは特殊な意味を持っています。
> つまり、Windowsはその環境サブシステムなくして動作しないのです。
> Windows環境サブシステムは、キーボード、マウス、ディスプレイを所有し、
> ログイン対話ユーザーを持たないサーバーシステムでも必要とされます。
> 残りの2つの環境サブシステムは、オンデマンドで組み入れられるにすぎません。
Xサーバーが提供すべきキーボード、マウス、ディスプレイを
Windows環境サブシステムが所有してるからWSLからは直接使用できない。
もちろんWindows環境サブシステムでXサーバーを作ればいいだけの話なんだが。
X Window Systemのアーキテクチャ的にもそれが素直な実装 Unicode対応というのは、UTF-8、UTF-16、UTF-32のいずれかが使われているということ
(他にUCS-2やUCS-4など今は殆ど使われていないものも有るが省略)
WindowsはNT3.1のころからUCS-2、Windows 2000からはUTF-16に対応している。
なぜUCS-2なのか?というとUTF-8もUTF-16も当時は存在していなかったから
つまりWindowsはかなり早い時期にとっくにUnicode対応をしている
■Windows は Shift-JISじゃなかったの!?
違う。一番わかり易い話をするならば、Shift-JISは日本語専用。言うまでもなくWindowsは多言語対応。
外国で日本語専用の文字コードが使われているわけがない。もう一つの例はファイル名に
「白抜きのハート」が使えることからも明らかにわかる。これはShift-JISにはなくUnicodeにしかない文字
どうしてこのような勘違いをする愚か者がいるのかというと、Unicodeに対応していない古いアプリの話をしてるから
Unicodeに対応していない古いアプリの互換性を維持するため(さすがWindowsの互換性は高い!!!)に、
「Unicode対応ではないプログラムの言語」の設定が日本語になっている
https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=019795
もちろんUnicode対応のアプリではUnicodeが使われる。だからWindowsはUnicode対応で、Shift-JISなのはアプリの問題
古いアプリを切りしてたら困るだろう?ちゃんとWindowsは対応してる。
■ 歴史
1991年10月 Unicode 1.0 (UCS-2登場 最大65,536文字)
1993年07月 Windows NT3.1 リリース (UCS-2対応)
1996年07月 Unicode 2.0 (UTF-16登場 最大1,048,576文字)
1996年09月 Windows NT3.5 リリース
1996年10月 ISO/IEC 10646-1:1993/Amd.1制定 Transformation Format for 16 planes of group 00 (UTF-16)
1996年10月 ISO/IEC 10646-1:1993/Amd.2制定 UCS Transformation Format 8 (UTF-8)
2000年02月 Windows 2000 リリース
■ 参考
https://ja.wikipedia.org/wiki/Microsoft_Layer_for_Unicode
https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows
https://ja.wikipedia.org/wiki/ISO/IEC_10646 >>574
元々Xerox のStarのコードで合った事の説明が無いな。書き直し。 WSL の gitをWindowsのソフトと連携できるようになるのはいつ頃かね
これが出来ないならWSL必要ないわ 元々UCSで世界中の現用の文字は全て収容できるはずだった。
16bit 65536個もの文字を収容できるコード体系だ、ぶっちゃけた話が、漢字さえ収まればなんとかなるだろう。
懸案の中国で、現在も使われている漢字は3万種程に収められるという。これならば数千文字を使う日本と分けても収まる。
UCSで文字コード体系の統一は可能だ。目途が立った。誰もがそう思った。俺だってそう思った。
…ところが、そうはいかなかった。
19200種もの文字種を要求してきた国があった。
韓国だ。
ハングルとは、いくつかの記号を組み合わせて作られる表音文字らしい。
しかし組み合わせの多くは実際には使われておらず、現用のものはわずか2000種類にも満たないという。
仮に論理上考えうる全ての組み合わせを実現した場合に、文字数は19200種類にも及ぶという。
韓国は、それを全部組み入れろと主張した。
中国が現在使われていない漢字については諦めて実利を取ると表明したにも関わらず、韓国だけはその卑しい要求を取り下げることはなかった。
この国は、どこかおかしい。
それまでその存在自体を認識していなかった若かりし頃の俺に、韓国という「頭のおかしい国」の存在ができた出来事が、このUCS騒動だった。
まだ2ちゃんねるなど出来るずっと前、おおっぴらに「韓国人?あああのキチガイ。」と話せる世相ができあがるより、ずっと前の話だ。 日本の漢字もやばいけどな
明治期に戸籍に書かれた誤字が大量に別物として存在してるしあるし unicodeに登録してあるのはある程度整理済みだが
実際は6万字以上存在する
渡邊だの渡邉だの
書き間違いとかも認めちゃってるんでしょ 有る無しじゃなくてそれを標準規格に組み込めってタダこねてるってことだろ 漢字に関しては統一して異字体セレクタで頑張れと言いたい
いっそ書き間違いセレクタでも作ろうかw
っていうかちょっと前にIPAが異字体セレクタ使いつつ6万文字の割当を完成させたニュースがあったような
ハングルは完成形で登録されてるのは1.2万文字程度だっけ
現代の韓国語で使われる組み合わせ全部
unicodeの前はよく使う約2千文字を収録した文字コードがあったけどそれだと外来語の表記ができなくて困ってたので全文字収録が望まれていた
(例えば슌(syun)が収録されてなかったので小栗旬とかのシュンを表記するのに仕方なく슈(syu)운(un)って書いたりとか) >>579
ユニコード出始めの頃からCJKVの国は一貫して勝手に決めるな西洋人めと反対してきた
ネトウヨの歴史修正主義をこんなところに持ち込むなや unix socketsがサポートされるということはdbusの実装も支障がなくなるな ていうか、もう出ないの?
諦めて、Ubuntuとかいうマイナーなの使った方が良いの? Fedoraなんてマイナーなのはサポートする気ありません
って言われたいのかな 確かに、Fedoraはマイナーかも。CentかRHELかOracleLinuxだよね。
RHELのライセンスってWindowsよりも高いし、
ちょっとした役割のサーバにも一括でRHELのライセンス買うので……
もしかして、WSLでFedora動いてもMSしかメリット無いだろ、
と思っているので、RH的にはあまり乗り気でないとか…… 今のMSならしれっとどんなディストリにも対応しそうな気がするw debianいいねえ
ubuntu微妙だし早く乗り換えたい もう、ubuntuで良いやと思って、入れてみたら、案外よかった。
というか、pythonやrubyで使うだけなら、あんまり影響ないね。
Windowsにruby入れても、Cのライブラリに依存するgemとか
インストールに苦戦するけれど、WSL上なら案外簡単に出来た。
でもyumだと-develというのが多いと思うんだけれど、
apt-getだと-devという名前が多いのね…… パッケージで何入れればいいか困ったら、apt-file使って適当なファイル名で検索すると分かるかもしれない。
GitはWSLのものをWidnowsアプリから呼び出せないものか・・・
Visual Studio Codeから使えるとGit Bashとか入れなくても済むんだけど。 細かい話なんですけれど、WSLのプロセスをWindows Firewallを使って送信制御とか
出来ないですよね?
仕方ないから、WSLを使うときは、一時的にフィルタリング無しに設定しています…… >>609
何故できないと思ったの?
そもそもファイアウォールの設定したことある? Windows Firewallってプロセス単位だっけ?
ポート単位でもできるんだっけ? プログラム単位でもできるしポート単位でもできるし色々できるぞ 随分と高機能になったよな
昔は内向きにしか対応してなかったのに Windows10 Home で、WSL(Windows Subsystem for Linux)正式版を簡単に導入できた
MS Store から簡単に、Ubuntu 16.04 をダウンロードできた。
サイズは、200MB ほど
パッケージマネージャーで、Ruby 2.3 も簡単にインストールできた Fedoraより先にRedstone 4が来るなこれは WSL で、Ubuntu 16.04 をダウンロードして、
sudo apt-get update
sudo apt-get dist-upgrade
それに、Ruby をインストールして、日本語ロケールを導入して、man を日本語化したら、
結局、850MB ほどになっていた Build 17093のWSLに関する変更点
ttps://kledgeb.blogspot.jp/2018/02/wsl-131-build-17093wslunixwsl.html
>「DrvFs」は、ディレクトリーごとに大文字・小文字の区別の有無を識別するフラグを設定できるようになりました。
>このフラグは各ディレクトリーごとに設定でき、このフラグが指定されたディレクトリー内に対するすべての操作は、
>大文字・小文字の区別が行われるようになります。
>またこのフラグが指定されたディレクトリーは、Windowsアプリも大文字・小文字を区別するようになります。 >>622
すごいな・・・
NTFSでは大文字小文字を区別できる能力はあったとは言え
Windowsで区別しないものを
WSLでは区別できるようにするとは
>またこのフラグが指定されたディレクトリーは、Windowsアプリも大文字・小文字を区別するようになります。
これもうコアレベルの修正じゃねーか
まあフラグ方式なら安全だろうけど >WSLでは区別できるようにするとは
ずっと前から区別してんのに何を今更なこと言ってんだろう 前世紀のPOSIXサブシステムですら大文字・小文字の区別はしてたんだけどな
https://technet.microsoft.com/ja-jp/library/mt629097(v=vs.85).aspx
Windows は大文字と小文字を区別しませんが、POSIX サブシステムでは大文字と小文字の区別がサポートされています。
このため、POSIX サブシステムのユーザーによって、
名前が同じで大文字と小文字の組み合わせだけが異なる別々のファイルが作成される可能性があります。
この場合、通常の Win32 ツールを使ってこれらのファイルにアクセスしようとしても
一方のファイルにしかアクセスできないため、ユーザーに混乱をもたらす可能性があります。 Windows側の、TeraPadで、ファイルを保存せずに編集しているけど、
クリップボード経由では、Linux側のvim, nano へ、paste できない
ファイルを一々、保存しなきゃいけないのか?
Windowsアプリの、win32yank を使うと、
クリップボードで渡せるみたいだが、皆どうしてる? おおー、vim, nano も、
右クリックメニューで、エディタ間の範囲のコピペも、自由にできる! おいカスども!
WSL入れたら次はX Windowだろうが!
貴様らASTEC-Xですか?
それともVcXsrvですか? >>632
ありがとうございます。
MobaXtermは試されましたでしょうか?
パッと見なかなか魅力的ですが。 >>633
mbaXterm 知らなかった。もろwsl用って感じてすね。
これからちょっと試してみる >>634
おっとっと
当方VcXsrvをお試し中 mobaXtermってmingw+パッケージ管理+ssh GUIという印象だったんだけど
WSLだとちょっと余計なものがつきすぎてるような >>638
方向性がまるっきし違うよ
mingwとかcygwinのそうだが、これらはWindows上で
動く新しいディストリを作るもの
Linuxカーネルは作らず、ディストリのみを作る
WSLはLinuxカーネルを作ろうとしている
ディストリは作らない。既存のディストリを拝借
前者は別のディストリなので、パッケージ管理システムは別だし
そのディストリ用にビルドが必要になる
本来カーネルレベルで必要なものをエミュレートしてるから
どうしても限界がある
それに対してWSLはLinuxカーネル互換機能をWindowsカーネルそのものに
追加しているから理論上はWindowsがLinuxそのものになる WSLは余計なものがつきすぎてるどころか
何もついていないと言ったほうがいい
パッケージ管理もGUI?もSSHもbashもWSLにはついていない
Linuxカーネル互換機能とディストリをブートする所までだ MobaXterm側に余計な物が付きすぎてるって話でしょ? >>639
こいついつも壊れたレコードみたいに同じ文章コピペしてんな >>639
>WSLはLinuxカーネル互換機能をWindowsカーネルそのものに追加している
そんな事してねーよ
環境サブシステムについて勉強しなおしてこい 638はmobaXtermはXサーバーとしては余計なものが付きすぎていると言っている
639はそのレスをWSLに余計なものが付きすぎていると誤解釈して突然の長文レスを投稿した可愛そうな人 WSLって大昔のPOSIXサブシステムみたいなもんか? あ、ウブンチュとか入れないとlsもできないからチョット違うか そうまでしてubuntu使いたいなら
もうwindows要らないじゃん ちょっと前までWSL使ってたけど、本物との微妙な違いに馴染めず
今じゃUbuntuをVMやDockerで使ってるわ。 >>638
>>634
msys2をつかっていて、wsl+ubuntu+cmder+VcXsrvに移行中の俺がmobaXtermを軽く使ってみている。
確かにお手軽でよい。インストールしていきなり使える。
見た目はかなりゴテゴテしているので、普段使いにはもう少し控え目がいいなぁ。
肝腎のXの性能はVcXsrvに比べてちょっともたつくような気がする。といっても、emacsしか使わないか。
そもそもsshクライアントなので、cmderと比べるのはフェアでないかな。
sshでの作業が多い職場での作業に役立ちそう。 なんかすまん…趣旨は>>643 の言うとおり
VcXsrvで今の所困ってないけど、VcXsrvがUnix domain socket対応したら
WSLとのやり取りはもうちょっと早くなるかもしれんね >>654
微妙な違いってどんなこと?
ほとんど違和感とか感じないで使っているので気になる >>657
違いというか、ファイルシステムが結局NTFSだからそれがボトルネックになってしまっている感じはあるな。 >>658
具体的に何で困っているのか、
後学のためお聞きしてよろしいか VcXsrvで日本語表示日本語入力できたけど
WindowsのIMEで日本語入力できた人いる?
IMEのユーザ辞書にイロイロ登録してるから
uimよりMS-IMEで入力したいんだよね。 >>661
ASTEC-X ならば可能のようです。
ttp://www.astec-x.com/FAQ/windows_ime.html 個人的にはcygwinとVM使ってるけど
どっちの代わりにもならんから使いどころが今のところわからない
特にvmはともかくcygwinの代わりには絶対ならなさそうなのが残念 ■ このスレッドは過去ログ倉庫に格納されています