この画面は、簡易表示です
ここ最近変化が無かったCANONのPIXUSが
という感じらしい。
なんで去年にこういうのが出なかったのかな・・・トホホ。
Windows 10 のコマンドプロンプトで
bashすると
>bash
— ベータ機能 —
これにより Windows に Ubuntu がインストールされます。Ubuntu は Canonical によって配布さ れる製品であり、
次のサイトに示される条件に基づいてライセンスされています。
https://aka.ms/uowtermsこの機能を使用するためには開発者モードを有効にする必要があります。
と出てくる。
いつもの様に
「設定」で検索しても「結果はありません：開発者モード」
「コントロールパネル」で検索しても「検索条件に一致する項目はありません。」
となるけど、素直に「設定」を開き、左のの「開発者向け」を押し「開発者向けの機能を使う」で【開発者モード】を選択すればいい。
何かのインストールを開始し「再起動するまでは一部の機能が使えないかも」と表示がでる。
>bash
— ベータ機能 —
これにより Windows に Ubuntu がインストールされます。Ubuntu は Canonical によって配布される製品であり、
次のサイトに示される条件に基づいてライセンスされています。
https://aka.ms/uowterms
続行するには、”y” を入力してください:ｙ
Windows ストアからダウンロードしています… ＊＊%
暫くまってみると
続行するには、”y” を入力してください: y
Windows ストアからダウンロードしています… 100%
ファイル システムを展開しています。この処理には数分かかります…
なるほど
既定の UNIX ユーザー アカウントを作成してください。ユーザー名は、Windows のユーザー名と一致する必要はありません。
詳細: https://aka.ms/wslusers を参照してください
新しい UNIX ユーザー名を入力してください: ＊＊＊＊＊＊
新しい UNIX パスワードを入力してください: ＊＊＊＊＊＊
新しい UNIX パスワードを再入力してください:＊＊＊＊＊＊
となるはずなんだろうけど
のようにカーソル位置がおかしくなっている。入力の入の右半分あたりにある。
passwd: password updated successfully
インストールが正常に終了しました
環境が間もなく開始されます…
ドキュメントを参照できる場所: https://aka.ms/wsldocs
******@*********:/mnt/c/Users/******$
で開始。
プロンプトは
{ユーザ名}@{マシン名}:/mnt/c/Users/{Windowsのユーザ名}$
なのでWindowsのファイルもアクセスできそう。
C:\Users\{Windowsのユーザ名}\AppData\Local\lxss に/bin などがある。
但しlxss自体は非表示属性で
フォルダの表示の「保護されたオペレーディングシステムファイルを表示しない（非推奨）」にチェックをいれないと見えない。
ls とか vi とか scpも使えるので、変なマシン名（記号含む等）にしていなければ（・＿・）ﾌﾂｳに使えそう。
ヘルプをみると
$ help
GNU bash, バージョン 4.3.11(1)-release (x86_64-pc-linux-gnu)
これらのシェルコマンドは内部で定義されています。`help’ と入力して一覧を参照してください。
`help 名前’ と入力すると `名前’ という関数のより詳しい説明が得られます。
‘info bash’ を使用するとシェル全般のより詳しい説明が得られます。
`man -k’ または info を使用すると一覧にないコマンドのより詳しい説明が得られます。
名前の後にアスタリスク (*) がある場合はそのコマンドが無効になっていることを意味します。
job_spec [&] history [-c] [-d offset] [n] または history -anrw [filename] >
(( expression )) if COMMANDS; then COMMANDS; [ elif COMMANDS; then COMMANDS>
. filename [arguments] jobs [-lnprs] [jobspec …] または jobs -x command [args]
: kill [-s sigspec | -n signum | -sigspec] pid | jobspec …>
[ arg… ] let 引数 [引数 …]
[[ expression ]] local [option] name[=value] …
alias [-p] [name[=value] … ] logout [n]
bg [job_spec …] mapfile [-n count] [-O origin] [-s count] [-t] [-u fd] [-C>
bind [-lpsvPSVX] [-m keymap] [-f filename] [-q name] [-u na> popd [-n] [+N | -N]
break [n] printf [-v var] format [arguments]
builtin [shell-builtin [arg …]] pushd [-n] [+N | -N | dir]
caller [expr] pwd [-LP]
case WORD in [PATTERN [| PATTERN]…) COMMANDS ;;]… esac read [-ers] [-a array] [-d delim] [-i text] [-n nchars] [->
cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s count] [-t] [-u fd] [>
command [-pVv] command [arg …] readonly [-aAf] [name[=value] …] または readonly -p
compgen [-abcdefgjksuv] [-o option] [-A action] [-G globpa> return [n]
complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action> select NAME [in WORDS … ;] do COMMANDS; done
compopt [-o|+o option] [-DE] [name …] set [-abefhkmnptuvxBCHP] [-o option-name] [–] [arg …]
continue [n] shift [n]
coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname …]
declare [-aAfFgilnrtux] [-p] [name[=value] …] source filename [arguments]
dirs [-clpv] [+N] [-N] suspend [-f]
disown [-h] [-ar] [jobspec …] test [expr]
echo [-neE] [arg …] time [-p] pipeline
enable [-a] [-dnps] [-f filename] [name …] times
eval [arg …] trap [-lp] [[arg] signal_spec …]
exec [-cl] [-a name] [command [arguments …]] [redirection> true
exit [n] type [-afptP] name [name …]
export [-fn] [name[=value] …] または export -p typeset [-aAfFgilrtux] [-p] name[=value] …
false ulimit [-SHabcdefilmnpqrstuvxT] [limit]
fc [-e ename] [-lnr] [first] [last] または fc -s [pat=rep] [co> umask [-p] [-S] [mode]
fg [job_spec] unalias [-a] name [name …]
for NAME [in WORDS … ] ; do COMMANDS; done unset [-f] [-v] [-n] [name …]
for (( exp1; exp2; exp3 )); do COMMANDS; done until COMMANDS; do COMMANDS; done
function name { COMMANDS ; } または name () { COMMANDS ; } 変数 – 変数の名前とその意味
getopts optstring name [arg] wait [-n] [id …]
hash [-lr] [-p pathname] [-dt] [name …] while COMMANDS; do COMMANDS; done
help [-dms] [pattern …] { COMMANDS ; }
となっている。
/bin や /usr/binの中にはいっぱいコマンドがあるので、これでも困らないかもしれない。
$ apt-get update
E: ロックファイル /var/lib/apt/lists/lock をオープンできません – open (13: 許可がありません)
E: ディレクトリ /var/lib/apt/lists/ をロックできません
E: ロックファイル /var/lib/dpkg/lock をオープンできません – open (13: 許可がありません)
E: 管理用ディレクトリ (/var/lib/dpkg/) をロックできません。root 権限で実行していますか?
おやルート権限が無いのか？
su –パスワード認証失敗
あれれ？
$ sudo apt-get update
sudo: ホスト＊＊＊＊＊ の名前解決ができません
[sudo] password for ＊＊＊＊＊＊:
取得:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB]
無視 http://archive.ubuntu.com trusty InRelease
取得:2 http://archive.ubuntu.com trusty-updates InRelease [65.9 kB]
取得:3 http://security.ubuntu.com trusty-security/main amd64 Packages [531 kB]
ヒット http://archive.ubuntu.com trusty-backports InRelease
ヒット http://archive.ubuntu.com trusty Release.gpg
取得:4 http://archive.ubuntu.com trusty-updates/main amd64 Packages [901 kB]
取得:5 http://security.ubuntu.com trusty-security/restricted amd64 Packages [13.0 kB]
取得:6 http://security.ubuntu.com trusty-security/universe amd64 Packages [138 kB]
取得:7 http://security.ubuntu.com trusty-security/multiverse amd64 Packages [5,198 B]
ヒット http://security.ubuntu.com trusty-security/main Translation-en
ヒット http://security.ubuntu.com trusty-security/multiverse Translation-en
ヒット http://security.ubuntu.com trusty-security/restricted Translation-en
ヒット http://security.ubuntu.com trusty-security/universe Translation-en
取得:8 http://archive.ubuntu.com trusty-updates/restricted amd64 Packages [15.9 kB]
取得:9 http://archive.ubuntu.com trusty-updates/universe amd64 Packages [376 kB]
取得:10 http://archive.ubuntu.com trusty-updates/multiverse amd64 Packages [15.0 kB]
ヒット http://archive.ubuntu.com trusty-updates/main Translation-en
ヒット http://archive.ubuntu.com trusty-updates/multiverse Translation-en
ヒット http://archive.ubuntu.com trusty-updates/restricted Translation-en
ヒット http://archive.ubuntu.com trusty-updates/universe Translation-en
ヒット http://archive.ubuntu.com trusty-backports/main amd64 Packages
ヒット http://archive.ubuntu.com trusty-backports/restricted amd64 Packages
ヒット http://archive.ubuntu.com trusty-backports/universe amd64 Packages
ヒット http://archive.ubuntu.com trusty-backports/multiverse amd64 Packages
ヒット http://archive.ubuntu.com trusty-backports/main Translation-en
ヒット http://archive.ubuntu.com trusty-backports/multiverse Translation-en
ヒット http://archive.ubuntu.com trusty-backports/restricted Translation-en
ヒット http://archive.ubuntu.com trusty-backports/universe Translation-en
ヒット http://archive.ubuntu.com trusty Release
ヒット http://archive.ubuntu.com trusty/main amd64 Packages
ヒット http://archive.ubuntu.com trusty/restricted amd64 Packages
ヒット http://archive.ubuntu.com trusty/universe amd64 Packages
ヒット http://archive.ubuntu.com trusty/multiverse amd64 Packages
取得:11 http://archive.ubuntu.com trusty/main Translation-ja [353 kB]
ヒット http://archive.ubuntu.com trusty/main Translation-en
取得:12 http://archive.ubuntu.com trusty/multiverse Translation-ja [8,774 B]
ヒット http://archive.ubuntu.com trusty/multiverse Translation-en
取得:13 http://archive.ubuntu.com trusty/restricted Translation-ja [480 B]
ヒット http://archive.ubuntu.com trusty/restricted Translation-en
取得:14 http://archive.ubuntu.com trusty/universe Translation-ja [1,087 kB]
ヒット http://archive.ubuntu.com trusty/universe Translation-en
無視 http://archive.ubuntu.com trusty/main Translation-ja_JP
無視 http://archive.ubuntu.com trusty/multiverse Translation-ja_JP
無視 http://archive.ubuntu.com trusty/restricted Translation-ja_JP
無視 http://archive.ubuntu.com trusty/universe Translation-ja_JP
3,576 kB を 39秒 で取得しました (90.8 kB/s)
パッケージリストを読み込んでいます… 完了%
$
でいいのかな？
GPUには処理を行う小さなプロセッサが多数搭載されている。
これをニューロ・チップに見立てれば、リアルタイムなCGを使ったゲームに特化したGPUがAIチップに変貌するらしい。
ボクはLISPをやっていたせいもあってAIとは、
の３ステップ（IPO）でありながらProcessを変化させることもできるプログラミング手法だと思ってる。
実際、大方のプログラミング手法ではProcess（≒プログラム≒実行ファイル）の部分は、プログラムの実行時は固定されている。その方が実行ファイルを情報の変更が面倒なROMに格納するのに都合が良かったせいでもある。
しかし、ブラウザのJavaScriptは、自分自身を書き換える（あるいは使っているライブラリィ群を切り替える）ことができた方が表現や目的に応じた処理を変幻自裁に変貌できるので都合が良い（画面のスタイルを変更する場合にプログラムの設定ファイルを書き換えて画面処理を再実行するより、CSSの参照先を書き換えて（あるいはCSSそのものを書き換えると画面が再描画してくれた方が便利な）ので先に述べたAI的な性質が大変強く、今ではAI的なプログラミング手法の方が目につくと云っていいだろう。
WindowsのOLEやJava言語はこの中間に位置し、プログラム・ソースを実行用にファイルに書き換えて（コンパイル）実行するので、「自分自身は書き換えできない」けど、「使っているライブラリィ群は切り替える」ことができる。
どれが優れているのかは用途に応じて変わってくる。Processを変化させることができることは便利であるが、外部からクラッキングされて書き換えられる恐れがあるので、所定の手続きを踏まないと書き換えられないことが望ましい用途で使うのは非常にリスクが高い。そんなことは一般のユーザには無縁の様な気がしそうだけど、オンライン・アップデートが一般化してくると、自分が使っている機器が勝手に書き換えられたり（いつのまにか自動のアップデートが処理され、旧データのファイルが読めなくなる）、勝手に画面が切り替わって（何かのアップデートが終わると勝手に再起動してしまう様なアップデート機能）しまうと困ることは多い。延々と文書を作成していたら画面が急に消えPCが再起動したのでPCが不調なのか？と思ったらWindowsのアップデートが始まったということがあった様な気がする。※ワイド画面の隅の後＊＊分後に再起動しますというメッセージを見過ごしていただけなのかもしれないが、さすがに最近はそう云う事態にはあっていない。
だからユーザが安心して使える方式がベストチョイスになる訳で、これは時期や風潮でどんどん変化してしまうものなので、どれが絶対良いということは無い。
先に述べたAIであっても、どの程度のProcessを書きられられるかを制御することは可能だが、LISPであればLISPのソースコードをデータとして読ませ評価すると、予想していなかった事態（Processの特定の部分は書き換えないように仕組みを作っていたにも関わらず、抜け道ができていた等）が起こり得る。LISPの評価処理はeval関数なのだが、JavaScriptの同名のeval関数がこれに該当する。
なので、AIにどんどんデータを読ませていくと、変な（想定していない書式の）データをうっかり読ませてしまうと、折角の学習時間が台無しになってしまうどころかProcessもおかしくなってしまってい復旧（元に戻す）ことさえ大変になることもある。有体に云えばバグとか不具合の類なのだけれど、LISPにとってeval関数はProcessの最上位の関数なので、使わない訳にはいかないし、Escape処理をしてデータがプログラム・コード化（Processの一部になったり書き換える）しないようにすると、評価できる範囲を狭めることになるので、用途に適さない場合もある。
ところが、GPUでは大方のプログラミング手法を利用しているようなので、GPUに組み込まれたProcessは書き換わらない様に思える。あくまでデータ処理を沢山のプロセッサで並行処理させるニューロ・チップとし処理させるらしく、変な（想定していない書式の）データをうっかり読ませてしまい折角の学習時間が台無しになることはあっても、Processまでもがおかしくなってしまうことはなさそうで、不具合の原因を調べて、Processを訂正し、「もう一度やり直せばいいや」という安心感はありそうだ。 ※でも、全くの勘違いかもしれない。
AIの最大の難点は、デバッグが可能かどうかである。Processを変幻自在に書き換えられては、どうデバッグするのか「適切に検討する」のは困難だ。ニューロ・チップについては脳細胞みたいなものという認識しかもっていないので、入力されたデータを沢山のプロセッサで色々な評価を同時並行で処理し、期待される処理時間内で、それなりの結果を返す回路だと思っている。その学習能力とはどんなものなのかも妄想するしかないのでかなり見当はずれだろうけど、「学習能力＝プロセス間の通信状態を良好に保つように各プロセッサの処理の分担を調整する」だと思う。例えば、ある作家の絵画の画像データから色の使用頻度、描かれている物体の形状の種類、その分散度、分散の偏りという評価結果を得る。それと画像データを調整（あるいは編集）するツールを組み合わせ、何かの写真を調整し、同様な評価結果がでるまで、しらみつぶしに調整する。その処理時間を集計し目立ったオーバーヘッドが見つかったら、そのオーバーヘッドの原因になった処理に対するプロセッサの数を増やしてみる、増やし過ぎたら逆方向に調整。暫く調整具合をみて、ほどほどのあたりで良しとする。なかんじだろうか？
しかし、これは手作業で行うのは非常に大変だ。似たようなものに「プログラムの高速化」があるけどこれはコードを見直すので「どうしても人手がかかる」し「専門的な知識や経験」がないと「時間を食う」だけで「良い結果が出ない」こともあるのだ。それが、目的に特化した最適なProcessが組み込まれたAIがあれば、たくさんのデータを読むことで、所定の処理時間内に、「それなりの結果」をだせるようになることは大きな意味があると思うし、自動運転の制御やビデオ映像をリアルタイムに誰かの作風の絵画の様にレンダリングしてみせることができるのだと思える。
そして、ゲームに特化したGPUにとっては、色々なゲームの様々な要求に、リアルタイムで処理できるようにしていることや、その調整のためにデータセンターのような巨大なテスト環境を持っているらしいので、すでにAI的というかニューロチップ的な手法を実践しているんだろうね。
でも一方では、目的に特化したProcessが組み込まれていないAIに、ただ絵画を入力しても、いつまでも「読みました＝True＝正常終了」と答えが出るだけだと思える。※この辺ですでに勘違いなのかも。
なので、AIとかニューロチップ（あるいはニューロネットワーク）に事前に何をどのように組み込むのかは「量子コンピュータ」と同じで、さっぱり解らない。
でも、それはその分野の専門家の領分なので、知らなくてもいいんだろう。
で、タイトルの「GPUはSFを越えられるのか」にやっと入る訳で、これは「単純には越えられない」と思う。
「GPUをSF映画にでてきそうな使い方をする」ことは「GPUにSF映画を模倣させた」と云うことだけど、それだけでも「GPUでSF映画が作れちゃう」様な感じなので結構凄い。しかし、「SFを越える」にはSF作家が考え付かなかったことをやればいいので「専門家にとっては案外身近な事象」を取り入れることで可能だろう。そうGPUのAIにSFをいっぱい読ませて、ガンガンSF小説を書かせたら物量的にSF作家を越えることができるだろうし、その中で傑作がでれば「実質的に越えた」ことになる。だが、それが良いことなのかを誰（あるいは何）が判断するのだろう？AIたるGPU？それとも人？なのか？
いづれにしても、GPUで処理するProcess自体は、組織情報やネット情報の集合知の結晶であり、結局は人手がかかる。ただ、人手を離れ（Process自体の開発が終了）しても、GPUが延々と処理しつつけることができるのが利点だが、その点が現状のネットと大きく異なっている。ネットが全自動で動作している様に思えるけど、それはネットワークを形成する沢山の通信装置や通信線そして沢山のデータセンターの設備であって、その設計や設置や運営はやはり人手がかかっている。つまりネットワークの維持やメンテナンス＝人力なので、永久に人手がかかる訳だ。これを省力化しようというのがIoTの一つの側面ではあるけれど、それでもやはり人力で維持されつづけることに変わりはない。
MAGNUS EN1070 GPU： GeForce GTX 1070
MAGNUS EN1060 GPU： GeForce GTX 1060
共通仕様
CPU： Core i5-6400T (quad-core, 2.2 GHz, up to 2.8 GHz)
メモリ： DDR4-1866/2133 SODIMM Slots (up to 32GB) ×２
ストレージ： 2.5-inch SATA 6.0 Gbps × １、M.2 PCIEx4 / SATA SSD slot (22/42,22/60,22/80) ×１
USB： USB 3.0 ×２ 、USB 3.1 Type-C ×１、USB 3.1 ×１ 、USB 2.0 ×２
サイズ： 210㎜ × 203㎜ × 62.2㎜
サイズも小さ目でゲームも十分できそう。
VESAマウンタは無い、ACアダプタなので電源部分は静かだが、CPUとGPUにそれぞれファンが付いているので、ゲーム時は煩いかもしれない。
一番の問題は、多分お高いんだろうなぁ。（笑
https:/
やっとボクの本命のグラボが出そうです。
チップの中身はGTX 1080 のおよそ半分。
但しGDDR5のメモリバスが192ビットと GTX 960の128ビットよりはマシになると予想されている。
拡張電源が6ピンのみで120W。
性能はGTX 980より速いらしい。
後は価格次第だけど、GTX 970より高い価格を出してきそうな気がしている。
その場合は年末セールまでお預けかな（笑
注意点としてはSLIのコネクタが無いこと。
Windows 10 の DirectX12 には複数のグラフィックスカードを入れた場合に全部使える機能（Explicit Multi Adapter(EMA)）があるので、もしかしたらコレでSLIもどきができるかもしれない。
当然DX9やDX11のゲームではできないし、ゲームやビデオカードのドライバがEMAに対応していることが必要だろう。
よくプレイしているFF14はDX9とDX11で、DX12では無い。
今は、DX11モードをONにすると、時々メモリーエラーやブルースクリーンやフリーズに悩まされるので、OFFにしている。
仮にDX12になって、EMAでプレイできるようになっても、トラブって、結局は「しばらくはお預け」ということもあるだろう。
そう考えると、FF14では2枚刺しはあまり意味はないと思う。
ps. 2016/07/19
FF14のpatch 3.35でエラー落ちのBugfixが入った。でもグラボを変えると・・・元の木阿弥になりそうなので、暫くはRADEON 7950のまま。
今メインパソでゲームするとたまにフリーズするので、Mini-ITxサイズの予備パソを用意した。
ケース： ENERMAX ECB1010 (Minimo.Q)
マザボ： ASROCK H110M-ITX/D3 BIOS:V1.60
CPU： Celeron G3900
メモリ: CFD Elixir Heatsink W3U1600HQ-4G （ DDR3 : 4GB×2枚）
電源：玄人志向 KRPW-SXP400W/90+ ワゴンセール品：普通のケースで使うためのアダプタ付、しかしファンの音が気になる。
※H110M-ITX/D3 はDDR3メモリが使えるマザボなので、余ったDDR3(2MB×2枚)を使う予定だったけど、相性が悪くi7-4770でも起動できなかったので、DDR3(4GB×2枚)を追加している。どうやらDouble-SideなDDR3は鬼門らしい。
メインパソが逝ってしまったら、この構成に、ほどほどのグラボを載せる予定だ。
先月予告されていたGTX 1070の後に出てくるハズの真のミドルレンジを予定していたら…
先にAMDからとっても安いものが出るらしいという情報が入ってきた。
日本での販売価格がとても気になってる。
いつもなら1ドル130円のレート＋プレミアムなので199ドルなら最低でも2万6千円を越えるはずだ。
性能はミドルレンジで、拡張電源コネクタも6ピン1個で、４００Wぐらいの電源ユニットなら大丈夫らしい。
多分発売直後にGTX 960 と RX 480 のベンチ比較記事が出るだろうから、そのあたりをよーく読んでから決めることにしようかな。
運が良ければ早めにGTX 1070 と RX 480 のベンチ比較記事も見れるかもしれない。
そんな訳で6月いっぱいゆっくりと考えて決めるのがいいだろう。
だから・・・6月いっぱいまではメインパソがもってほしいぃなぁ・・・（無理かな？
最近FF14に復帰して以来、パソが時々フリーズするになったので、気になって仕方がないGeForce GTX 1080。
性能が上がっているのに消費電力(TDP)が200W未満なのが一番気に入っている。
VRAMは諸所の都合でHBM2ではなくGDDR5Xでメモリバスは256bitになっているが、メモリの性能がずば抜けているので、大きな問題にはならないらしい。
まだ時々めまいがするので、VRやHMDは使わないつもりなので、オーバースペックかもしれないが、同じグラボ（HD7950）を何年もFF14でプレイするのはさすがにグラボに負担（特にファン）がかかるだろうから、来年中には何かにアップグレードしようかと思っている。
※ID（ダンジョン）を初回クリアした後にエフェクト満載のムービーが流れるとグラボのファンの回転数が一気に上がるのでムービーが一番無理をかかっている気がしている。
FF14ではPS4のゲームパッドを使っているので、HMDを装備してプレイしても支障はない様な気もするが、HMDを装着したままキ－ボードでチャットは無理だろう。
え？常時ソロプレイだからチャット不要のハズ？
ID（ダンジョン）では「初見です。よろしくお願いします。」と、ちゃんと挨拶してますよ。
※「初見です。」と云わないと・・・「ギミックを踏んで頓死しても蘇生してもらえない」
※ボクが行く様なIDでは慣れれば誰も死なないから・・・ボスを倒した後にHP０に気が付くヒーラーは多い。
ゲームパッド使用時もキーボードは必須です！
ただボクの予算は少ないので、いづれAMDがPolarisのミドルレンジのグラボが出し、nVidiaが対抗してミドルレンジのグラボ（1060かな？）が出るだろうから、そのどちらかがボクの本命になりそうだ。
それに（グラフィックスの性能次第だけど・・・）、2016年中に出るかもしれないZen（APU版）を水冷し、mini-ITXケースという選択肢も残っている。
年末には、どれになっているだろうか？
ファイルサーバのEXCELファイルを開くと セキュリティ警告 のバーが出る。
しかし、このバーを閉じ保存しても、開くとまた出てくる。
なので、ファイルのある場所を「信頼できる場所」に登録しなければならないらしい。
当然サブフォルダも含める様にした方がいい。
今更bashが使えたところでどうでもいいと思っている。
Bashの中では文字コードセットがUTF-8らしいので、Linux系のＧｉｔＨｕｂからパッケージのソースをダウンロードし、ビルドして、使えれば便利かもしれない。
しかし、Linuxのパッケージのビルドでよく使う make install もMS仕様のmakeはMakeFileでルールを記述する順序がLinux仕様のmakeと逆なので、Linux仕様のmake コマンドがなければ無理、ファイルやバックアップでファイル転送によく使うscpコマンドも多分無いだろう、勿論Windowsのアプリで代用できる場合が多いけど、スクリプトを全て読んで書き換えるのは多分骨が折れるし、GUIのアプリは起動すると一番手前に配置されるので、スクリプト実行中はデスクトップは放置状態にしておかないと、ESCキーを押したらスクリプトから起動したアプリを止めてしまったとか・・・、長いオプションの代わりにクリップボードが使われていた・・・（汗という状況に陥る可能性がある。気が付く分だけでも、結構あるし、Linuxではスクリプトからスクリプトを呼び出すなんてことはごく普通にやっていることで、まだまだLinuxで普段気が付かないまま使っているコマンドや言語もいっぱいある様な気がする。
そうLinuxで必要とする言語の数は結構多い。ざっくりと「Perl、C、C++、Java、Python、PHP、Tcl/Tk で十分！」と勝手に決め打ちしても、やはりシェルスクリプトの中でパッケージの設定ファイルの編集に何気なくsedやawkなどを使っている場合もあるだろう。だからこそ、Windowsで使えるbashもドコかにyumのようなオンライン・リポジトリィを作っておかないと後々大変だろう。
で、そこまでやるならHyper-VでCentOS7のゲストOSを作り、NFSでWindowsのドライブをマウントした方が楽な気がするんだよね。
どうしてもWindowsOSの環境下でbashを実行したい向けかな？