Win10がBash・linuxｺﾏﾝﾄﾞに公式ネイティブ対応★3 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
http://o.aolcdn.com/hss/storage/midas/abc336039023870541d79f90e3daefeb/203619879/bash-windows-10.jpg
本日から始まった開発者カンファレンス Build 2016で、マイクロソフトがWindows専業以外の開発者にも嬉しいニュースを投下しました。
Windows 10は今年夏に提供予定の一周年アップデートから、Unix / LinuxのコマンドシェルBashが使えるようになります。
http://o.aolcdn.com/hss/storage/midas/842936fc527a08e80d1305a6861b65f7/203621101/image_2fe8f62c-c4d1-4cba-863c-db5e9c60b4f8.png
Windowsには cmd.exe や PowerShell など自前のコマンドライン環境がありますが、Unix / Linux の Bash は当然ながらそのままでは動きません。
Bash や Linux / Unix 向けに書かれた多くのコマンドラインツールが使えないため、Unix系の開発者からWindows
が「『本物の』コマンドラインも使えないOS」呼ばわりされたり、開発者にOS Xが好まれる理由になってきました。
しかし本日から始まった Build 2016カンファレンスのキーノートでは開発者向けの新機能として、Ubuntu Linux のBashがそのまま、
Windows上でネイティブ動作する機能の追加予定が発表されました。
これはマイクロソフト版のBashっぽい何かではなく、またVM上の動作でもなく、新たに開発された
「Windows Subsystem for Linux (WSL)」を介したネイティブ動作であるとのこと。BashのバイナリはUbuntu Linuxの
開発を主導するCanonicalが、Ubuntuとまったく同じものを提供します。
Bash on Ubuntu on Windows 10は、今年夏に提供予定のWindows 10 Anniversary Update に含まれる見込み。
Windows 10 now has support for Bash and the universe of open source command line tools. #Build2016 pic.twitter.com/5KeBeVg0wU
― Windows Developer (@windowsdev) March 30, 2016
AOL 2016年03月31日 06時15分
http://japanese.engadget.com/2016/03/30/windows-10-bash-ubuntu-linux/
前スレ 【Win10でlinuxコマンドが使える】Windows10がBashに公式ネイティブ対応 ★２
http://daily.2ch.net/test/read.cgi/news plus/1459471519/ 有料になる前にWindows 10に乗り換えておこう )()((()()(())()((()(((())(())(()))))(((())))))()()))((()))(((((())(())())
))))(()()))(()((()(()()())())()())))((())(())(()()()(()(())((((())))(()((
((())))())())()())())((()))(((())()(()))()(()()()()())()())(())()(()(((((
())(()())(()(())())(()()(((())))())(((()))()()))((())()))(()(((())))(()((
()()))(((())()))((())()(((()(())))((())))())((((())())()(()())((()()()())
)()(())(())()(()(()(())((()(((((()()))())))()))(()(()(()(()())))()((())))
()(((((())()))())))(((((())((())()(()(()))())))())))()))((((())))(((())((
(()())())))())()())())()())(((()))))))())(((((())((()(())(((()())(()(()((
()(())()))()()()(()()(()(()))(()())()))((((())))(())())())()()((((()))(((
(((()()())())()))(()(()((((()((()())((()(((())))())(()()))()(())))))())()
)())())())))((((()(()(())))((()))())(())()(()(()(())))(())(((((()(())(())
(())(()(((())((())(()()(()))))))))(())((())())((()()()()((())))(()))((()(
))((()()()))(()))()))))))())((()(()))()(((()(()()))()(()(()(()(()()(()(((
))))))(())(()(())(()()()(((())(()))(((((((()))(()())())((()))))(()()())((
))))(()))(()())()(((((()))(())(((())()()))(((()())((()))(()(())(())())(()
(())((()()))))()()()(()(((((())())(())))(((()(()))))()(())(()()())()())((
(((((()(()))()))((())(()))(()()((()))))))))()))()))()((()((()(((())()()((
(())((((((()))))))(()(())))(())))()((()(((()))())()())))((((((())()())()(
()()))()))(())))))))()()()(((())()()))(((())))()(())))(()()((()((((((((((
)))(()((())())((()(()())(()((()))((()))(())))((()(()))(((())))()()(()()()
))))()())(()(((())(()))(((((()))(()()()((())(()))))))((()(()()))())(()(((
)()((())()((())(()((()(((()()))())()))()()()()()))(()()(((()((()()())))))
()()(()())((()()(()()()(((())(()))(())())((()))))))(())))())(()((())(()((
(()())))(()((())(()((()()(()()())())(()(())(((()))))(()(((())(())))()()))
()()(((())()))(()((()())()))()(((()()))())()((((()()())))(()((())()(())))
))()()()(())))((()())(((((((())((()))))())))()))()))((((()))))((()(((()(( XもないLinuxもどきなんて
今時のLinuxユーザーはGUIの開発ツールをがんがん使ってるのに、いまさらこんな子供だましでどうすんの？
開発者向けというけど、Windowsの上のLinux向けCUIツールで、何を開発するんだろうか Bashで動かしている限りはディレクトリは￥じゃなくて/で、オプションは - が使えるの？ あー、でもMacみたいに /usr/local/{bin, lib, libexec, share} とか作れなきゃ意味ないのかな？ >>5
GUIならWindowsを使えばいい。
Linuxはサーバー用途だ。
CLIだけでも十分。
もっともXクライアントは動くと思われるので
Windows用のXサーバーを入れれば
LinuxのGUIアプリは使える。 >>6
Linuxのバイナリがそのまま使えるので
パスや各種オプションはすべてLinuxとおなじになる。 >>7
当然作れる。
MacはUnixなのでコマンドが微妙に違うが、
LinuxサブシステムはUbuntuそのもの 動くだろうな。
動かないものがあるとしたら、未実装のシステムコールを使うものとか
システムコールの互換性が十分でないものとかに限られるだろうから
slコマンドのような画面に描画するだけのものは動くだろう。 >>6
今までのSFUやSUAはそうなってた。が、シンボリックリンクとかは、UNIX側世界でのみ有効。Windows側で見ると、ただのファイルだった。
今回のも、中途半端にLinuxとWindowsが混ざった、どっちつかずの使いにくいものになると思われる コマンドライン文字列の扱いが平たくなるといいなあ。 >>14
そういう意味じゃねーよ。
これはUbuntuなんだから、実際のサーバーはUbuntu使えばいいだろ。
俺が言ってるのは、GUIが必須だとかアホなこと抜かしてるから、
GUIなんていらねーだろ。主にサーバーで使ってるんだから。
って話だ >>13
> 今回のも、中途半端にLinuxとWindowsが混ざった、どっちつかずの使いにくいものになると思われる
混ぜようと考えるから、どっちつかずになるんだよ。
これは混ぜない。ディスクをマウントしているだけ。
Linuxサブシステムで動かすものは、すべてLinuxで動かすものと考えればいい。
ただしブラウザやIDEやテキストエディタ等でファイル編集するときは
WindowsのGUIツールを使える Announcing Windows 10 Insider Preview Build 14316
https://blogs.windows.com/windowsexperience/2016/04/06/announcing-windows-10-insider-preview-build-14316/
Run native Bash on Ubuntu on Windows: In this build, you can natively run Bash in Windows as announced last week at Build 2016.
To do this, you first need to turn on Developer Mode via Settings > Update & security > For developers.
Then search for “Windows Features” and choose “Turn Windows features on or off” and enable Windows Subsystem for Linux (Beta).
To get Bash installed, open Command Prompt and type “bash”. For more details, see this blog post. 【2016年4月6日】 Windows10 ビルド14316公開 話題のBashとLinuxコマンドが使用可能に！ [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/pcnews/1459967838/ まだこの生産性のない話題続けんの？
誰も使わんよこんなもの。 >>20
誰も使わないモノをどうしてMSが実装することにしたんだろうね？
開発環境をOSXに奪われつつあるからだと思ってるんだけど。
まぁ俺みたいなプレインスコ機使ってる事務屋には関係ないんだけど。 >>20
それな
互換の話題って結局何もしてないようなもんだ >>23
/etc/resolv.confに
nameserver 8.8.8.8
と書いてあげる。
8.8.8.8はGoogleのDNSサーバー。
自宅で使ってるDNSサーバー（例えばルーターのIPアドレス）でもよい このウブンツを窓のユーザランドから観たとき、どう映るかだな
ファイルシステムをネットワークを通さず共有できるのか？
マルチドライブ環境がどう映るのか？
ネットワークインターフェイスでtcpスタックを共有できるのか？
ウブンツシェルから窓のコマンドをキックして、そのプロセスをキルできるのか？
シグナルはとばせるのか？
NTFS ACLを操作できるのか？
セマフォ、ミューテックス、共有メモリを窓と共有、連動するのか？
最低限これができなくてはただの仮想マシン 少しは調べてから言えよアホ
> ファイルシステムをネットワークを通さず共有できるのか？
できる
> マルチドライブ環境がどう映るのか？
マウント済み
> ネットワークインターフェイスでtcpスタックを共有できるのか？
できる
> ウブンツシェルから窓のコマンドをキックして、そのプロセスをキルできるのか？
不要。何のためにしたいのか？
> シグナルはとばせるのか？
可能
> NTFS ACLを操作できるのか？
現時点では出来ない
> セマフォ、ミューテックス、共有メモリを窓と共有、連動するのか？
現時点では出来ない。というか最初からそういう用途じゃない
> 最低限これができなくてはただの仮想マシン
マシンをエミュレートしてないので仮想マシンではない
仮想マシンの条件を満たしてないものを、仮想マシンと呼ぶのはアホ ちょっとずつアップデートしながらubuntuに置き換わって行くんだなきっと >>28
GUIデスクトップを専有しているのは
あくまでWindowsなのでそれはないよｗ
Xクライアントは動いても、Xサーバーはデスクトップを
専有しているWindowsで動かす必要があるからね
MSがやろうとしているのはLinuxで動く
各サーバーアプリをWindowsでも動くようにすること。
特に開発用途としてね。
さまざまCLIコマンドが使えるようになるし、
仮想マシンはメモリ食いって言う問題を解決してくれる。 >>29
サーバーアプリは推奨されてないよ。その用途なら仮想化したほうがはるかにいい。 >>30
サーバー用途として使うのがだめで（当然だｗ）
開発用としてサーバーアプリを使うのは推奨されている。
だから
http://sqlazure.jp/r/tips/794/
Redisが動くとか、MySQLはまだ問題があるって話が出てるんだ。
っていうかさ、お前分かってやってるよね？
もう二度とサーバーアプリは推奨されてないとか
仮想マシン使うとか言う話しないでね。キモいから >>31
そうですね、ありがとう。
君は詳しいようだけど、人間的にダメだね。 これってBash.exeの上でubuntu環境ができてるだけだね。
tcshにしたくても、まずbash.exeを起動してからtcshを起動するしか無い。
NTカーネルおじさんがPEかELFか判断してそれぞれのsubsystemに振り分けてくれる感じだと歓喜なんだけども。 Cygwin 入れて bash 使うのと比べてなんかいいことあるの？ >>34
作るのは簡単だけど、ELF形式のウイルスとか送られてきたときに困るから
いろいろ考える必要があるよ。実行権限をどうするかとかさ。
やりようはいくらでもあるが、Windows自体に修正が必要になるので
ベータの段階でそこまでやらない。
まずはLinuxカーネル相当の機能を充実してからだろう。 >>36
メリットはLinuxそのもののバイナリが動くから互換性が高いし、おそらく高速。
デメリットはwindowsのソフトを呼び出せない。 >>36
OS標準機能に加えて、Win32APIに変換しない分
パフォーマンスが良くなる。 >>38
> デメリットはwindowsのソフトを呼び出せない。
呼び出したいことはないので、デメリットにならない。
お前、しつこいよね。
お前しかその点を指摘してない。
あぁ、キモイキモイｗ >>41
君としてはデメリットにならないってのは
それはそういう人もいるでしょうし、否定はしませんが。 >>41
う〜ん、君は能力あるのに残念だねぇ。
もう少し寛容になって人格者になるとすごく幸せな人生に
なると思うよ。 bashからWindows版VSCode呼び出して編集してたけど >>45
GOWやらcygwin、msysならできますが、今回のものはできなさそうですね。
私もWindows上のエディタを呼び出して編集することが多いですが
デメリットに感じますね。
「そんなもんつかわんからデメリットになるわけないだろ。
viかemacsに決まってるだ。あぁ、キモイキモイｗ」
とかいう人が出そうだけどね。 作るのが簡単とかいうのは簡単だよね。
ELFのウィルスが不安って、PEのウィルスは不安じゃ無いのかな？全く根拠無いよね。
Ubuntu on Windows じゃなくて、あえて
Bash on Ubuntu on Windows と言ってるところが、あぁそういうことか、と思い知らされた瞬間。 >>47
cygwinやMinGWと何が違うの？
ELFが動かなくてリコンパイルが必要なら、今までも色々あったわけで。あっ、ただの宣伝か… orz >>50
サポートがある。これが重要。
個人で使ってる分には必要ないけどね。 >>27
なかなか詳しそうだ
共有メモリ、セマフォが窓と連動、共有できないとリソース把握できない。
別々にパーティショニングされてしまうと、ならば完全な仮想マシンでいいじゃないかとなる。
無駄にファイルシステムを共有できるから、ウブンツ側から窓のファイルを弄る危険性をはらむ。
NTFSのアクセス制御がオーナパーミッションのみでしか判定されないとか、汎用パーミッション(GENERICを満たさないとダメ。サブフォルダの削除だけ不許可とか、禁止ACE)でしか扱えないだと、
結局はウブンツを封じ込めて使うしかなくなる。 ライブラリ抜き出して他のWindowsで使う方法が見つかったら起こしてくれ >>52
> 共有メモリ、セマフォが窓と連動、共有できないとリソース把握できない。
リソース把握して何がしたいんでしょうかね？ｗ
> 別々にパーティショニングされてしまうと、ならば完全な仮想マシンでいいじゃないかとなる。
仮想マシンは重いし手間がかかりますからね。
apt-get でRedisをインストールして実行
VS 仮想マシン作成してUbuntuをインストールして・・・
面倒くさい、面倒くさいｗ >>52
> 共有できないとリソース把握できない。
> 無駄にファイルシステムを共有できるから、
共有したいんでしょうか、共有したくないんでしょうか？ｗ
言ってることが矛盾してますね。
最初から結論ありきで、どちらであっても
叩こうとしていますねｗｗｗ >>52
Windowsの世界からLinuxを世界を操作することはあまり想定してないでしょ。
かなり作りこまないといけないのに、MSにメリットが少なすぎる。
Windows中心で、Ubuntuで簡単に管理できるツールも使いたい、
これがMSの想定している用途では? >>59
Windowsとの比較で言うとMac OS Xは最初から生まれてもいない。
とMac OS X上のBathyScapheから書き込み >>60
単にLinuxを道具として使いたいだけでしょうね。使える道具を増やすのはいいこと。
いまさらながら柔軟で優秀なカーネルなんですね。 Windows bashがくるまではコチラで遊べる
Microsoft純正UNIXサブシステムinterix
http://unix.oskp.net/sua >>64
サイト管理者本人か?
2012年にMSにInterixが捨てられてからもページを維持していたかいがあったなw
WSLはInterixの改造版なのかもね とりあえず、お前らFAQくらいは読めよ
https://msdn.microsoft.com/en-us/commandline/wsl/faq
非公式日本語訳
ttp://kledgeb.blogspot.jp/2016/04/wsl-1-ubuntu-on-windowsubuntu-on.html 取り敢えずgccが使えれば新人研修が楽になるなぁ･･･と思った。 >>69
ネタはいいよ。gccぐらいだったら今まででも何とでもなってたし。 Xクライアントがdbus絡みで動かない件、
Windowsでも、winDBusってのがあるみたいだな。
もしかして使えたりするのかな？ >>67
非公式日本語訳
ttp://kledgeb.blogspot.jp/2016/04/wsl-1-ubuntu-on-windowsubuntu-on.html
> もし「grep」コマンドが「Ubuntu on Windows」に含まれていなかったら、
> 以下のコマンドを実行して「grep」パッケージをインストールすれば、
> 「grep」コマンドが利用できるようになるでしょう。
>
> [ apt install grep ]
おいしっかりしろapt-getだろ ttps://www.youtube.com/watch?v=kQd3nwmJLuc
まあ予感はしてたけど・・・ コマンドプロンプトからじゃなくてminttyみたいなの実装しないと日本語やカラー表示周りで激しくgdる悪寒
sshクライアントで接続したり出来るようにすれば解決したりするんかのう？ これで何が便利になるかって、ログファイルをtailできることやな
Windowsソフト（フリーとか）もあるが、常用に耐えん >>79
OSXのコマンドラインは固有機能への拡張が色々と成されてるから便利だけどね Windows 10のbashでLinux GUIアプリやｘを動かす人が現れる
ttp://www.neowin.net/news/bash-plus-windows-10-equals-linux-gui-apps-on-the-windows-desktop やはり日本語はダメらしいね
http://www.atmarkit.co.jp/ait/articles/1604/11/news031.html
これを機にWindowsもUTF8デフォになってくれないかな
ついでにドライブレター廃止とファイルセパレータを／に変えるというのも
そもそもどうして内部コードをUTF16なんかにしちまったのか
メモ帳でUTF8ファイルを更新するとBOMがくっついてしまうマヌケな仕様もおそらくそれが原因
サーバー環境だと使えるエディタがメモ帳しかない場合が多いから、WindowsでUTF8は実質使えないのよね そういやLinuxはutf8か
昔のMicrosoftなら末尾UのApi作って8対応しそうなんだがな
どっか新しいOS作ってくれないかな
マックはお話にならん >>85
> そもそもどうして内部コードをUTF16なんかにしちまったのか
Windows が Unicodeに対応したNT 3.1（1993年7月リリース）を開発していた時点で
UTF-8（1993年1月発表）が存在していなかったから。
UTF-16は1989年にドラフト、1991年に1.0がリリースされている。
そもそもUTF-8が出来たのはUnixやLinuxが、1文字を2バイト固定で
扱うと言う変更についていけなかったのが理由。
C言語がASCII前提でライブラリの殆どが1バイトづつ処理しているからね。
1文字2バイトの片方に終端文字と同じ\x00が入ることがあるエンコードへの対応は困難
UTF-8にしていればというが、それは結果論ってやつでWindowsは
最先端OSだったからからこそ、当時存在していた最先端の仕様を
採用したに過ぎない。 >>85
utf8はCodePage 65001に割り当てられてるので、自分でutf8対応のアプリを書くのは問題無い。
ただ System CodePage に依存してるアプリが多すぎてデフォルトを変えると文字化けだらけになるよ。 >>88
随分とできの悪いOSだなｗｗ 出たばかりだというのに。 >>89
出来が悪いのはOSじゃなくてアプリだと書いてあるのに理解できなかったかな？
出来が悪い>>89ですね。
ちなみにOSはパスセパレーターに/も使える。
もし/が使えないならそれもアプリのせいだからな。 >>90
いや、訂正するわ
出来が悪いのはお前の脳みそだわ。悪かったな。 言ってることが「バーカーバーカ」レベルのやつがいるなｗ 単にbashだけでなくてgawkなんかも使えるのな
テキストファイル整形捗るわこりゃ
他にも要るのあったらapt-getできるとかすげーな
そういえばvim試してなかった ピコーン！
いいこと思いついた！
wine使えばいいんじゃね？ >>85
>これを機に
それだけはないw
仮にやるとしてこんなのがきっかけにはならん >>87
UTF-8の絶対的な有利性が理解できないとはw
UNIXだけの問題じゃないよ >>77
sshでログインした時はsshd側はttyデバイスはほぼ使わないに等しいから問題ない
sshクライアント側のVT100エミュレーションがちゃんとしてればいいから
端末の動作の多くはVT100エミュレーションのエスケープシーケンスでリモートコントロールだから
同じマシンでも例えばputtyからログインすればいい >>97
開発時に存在していなかったものの採用なんてできるわけがないし、
今UTF-8が標準になっているだけであって、
絶対的な有利性というものは存在しない。 >>99
Mac OS Xは
NEXTSTEPの日本語版時代はEUCやShift JIS
Mac OS X自体も初期は開発系はShift JISだった
徐々に移行出来てる
MSは技術の移行が下手 ■ このスレッドは過去ログ倉庫に格納されています
