MSのコマンド プロンプトは実に酷い。
例えば、Windows 7までなら、
C:> mem
で、使用できるメモリ容量（640KB前後）が判ったが、Windows 8.x には勝手に無くなっている。
BATファイルでIF文でブロック形式で記述できるようになって久しいが、
@echo off
SET V1=ABCDEFG
echo "(1) V1=%V1%"
IF 1==1 (
SET V1=123
echo "(2) V1=%V1%"
IF %V1%==123 (
echo "(3) V1=%V1%"
) else (
echo "(4) V1=%V1%"
)
echo "(5) V1=%V1%"
)
echo "(6) V1=%V1%"
IF 1==1 (
SET V1=123
)
IF 1==1 (
echo "(7) V1=%V1%"
)
PAUSE
をWindows 8.xで実行すると
"(1) V1=ABCDEFG"
"(2) V1=ABCDEFG"
"(4) V1=ABCDEFG"
"(5) V1=ABCDEFG"
"(6) V1=123"
"(7) V1=123"
続行するには何かキーを押してください . . .
IF文のブロックで変数を変更してもIF文の外に出てからやっと同期がとれる。
もし、パラメータの設定具合で、色々調整して何か実行するなら、
if Aの場合 (
変数１の変更
変数２の変更
・・・
変数ｎの変更
)
if Aの場合 (
何かを実行 変数１、変数２・・・変数ｎ
)
と書いておかないと、
最初のうちはちゃんと動いていたBATファイルが、変更を加えているウチに急に動かなくなる事態に直面してしまった。
普通なら、ちゃんと文法や注意事項を読めば、何が悪いのかは直に判るハズなのだが、
状況がいっきなり変わる！
少し追加したり削ったりすると・・・文法が間違っている！宣言されていません！＊＊＊の使い方が間違っている！
と散々な状況に陥り、テキストエディタでソースをUNDOしても・・・状況は変わらない？？？
たぶん、リポジトリィがらみの互換性調整機能が中途半端に働いて後戻りできなくなっているのだろうと思っているけどね。
そんな訳で・・・
まだ、頭の中はかなり＊＊＊＊きている。
なぜ、こうなるのかは、Windows 8.xで
C:> HELP IF
の説明を最後まで読んでも、 遅延環境変数の展開 のコトは1文字もない。
どうしてもスッキリしたい場合は、
setlocal enabledelayedexpansion
を宣言し
if !V1! == 2
のように書けばいいらしいが、うまくいかなかった。
また、よく判らない制約事項として
CMDやBATの拡張子のファイルで「編集」を選択すると、メモ帖が開くが これを他の拡張子の様に簡単に他のテキストエディタに変更することができない。
for %変数名 IN (セット) DO コマンド
の変数は、BATファイルでは %%変数名 と書かなくてはいけない。
SET 変数=”ABCD EFG”
と設定値に空白が入る場合を考慮して ”で括ると、設定値に”までもが付いてくるので、
使用時は %変数:~% と “ を取り除かなければいけないから、
外部ＢＡＴファイルにパラメータとして引き渡す場合は、変数だから ”％変数名：～％” で、パラメータだから ”％～１％” とか 気を付けないといけないし、
外部ＢＡＴファイルの方も、”％～１％”で使う様にしないといけない。
さらに厄介なのは全角の空白も”で括らないと半角空白同様にデリミタとして扱われるっぽい。
なので、普段から
SET %変数名=”＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊”
SET %変数名=%変数名：～％
と2行で書くクセを付けた方がいい。
“％変数名：～％”の場合、先頭１文字は”％変数名：～1,1％”で読み取れるが、”％変数名：～0,1％”とすると、～で取ったハズの真の先頭の”が取り出せる。
“％変数名：～％” と ”％変数名：～1,-1％” は結果が大体同じ。
・・・
と、貧相なメモリしかないMS-DOSの時代には許されていた変態仕様のコマンドプロンプトのスクリプトも昔に書いた短いスクリプトのためには必要だろう。
・・・
だが、新たにBATファイルを作ると
・・・
どう考えてもダラダラと長いBATファイルにしかならない。
・・・
もう
ストレートにBATファイルの中からCScriptを呼び出し、
主なコードはJScriptで書いた方が良いだろう。
だが、まともに書くと、BATファイルに
cscript //logo %~dpABC.vbs
と書き、ABC.vbsファイルを別途に用意しないといけないので
・・・
CScriptブートストラップ
@if (1==1) /*
@ECHO off
echo パラメータ付きでこのファイルをJScriptで実行する。
%~d0
cd %~dp0
CScript //Nologo //E:JScript “%~f0” %*
REM ファイルの最後まで読み飛ばす
GOTO :EOF
rem */
@end
/* JScriptで実行する部分 */
// 主処理の呼び出し
WScript.quit(main(WScript.arguments.length, WScript.arguments));
// 主処理
function main( argc, argv ) {
WScript.echo(“今はJScriptらしい”);
}
と、最初にJScriptを呼び出すブートストラップ・コードを付ければ、いくつもファイルをセットで用意しなくていい。
下地としてEXCELのVBAのエディタでインラインのヘルプを使ってコーディングし、そっくり貼り付けると多少楽かもしれない。
Visual Studio をインストしてあれば、ＩＥのエディタにJavaScriptデバッガが付くのでここでデバッグすればかなり楽だろうけど、今時分はＩＥを使うのはとても怖い。
コマンドプロンプトで、ゴニュゴニュしなくても、JScriptをBAT風に実行できるのはとても楽だが、デスクトップにショートカットを貼ってパラメータを付けて使った方がいいだろう。
JScriptのどこが良いのかと云えば、
- MS純正のMS-DOSスクリプトでは、「＊＊＊の文法が間違っています。」としかエラーが出なのでデバッグにかなり手間取るが、JScriptで実行中のエラーは(34,2)の様にエラー個所を指摘してくれる。
- 純正のＢＡＴコマンドには各Windowsのローカル仕様が混入されており、Windows Serverでも、Windows VISTAでも動く様に作ったスクリプトも数年ごとにやってくる新しいWindowsの出現により崩壊する。
- たった数行のシェルスクリプトを動かすために、Cygwinをインストし、更に Windowsだから、アレは！コレは！と頭をひねって使うよりマシだ。
なにげに見つけたxls2csv.batは、お手軽でとても良いツールだ。
難点を云えば、
WScript.CreateObject
がtry catch で括られていないせいか？、沢山のXLSファイルを変換する最中にスクリプトをCtrl+Cで止めるとEXCELというプロセスがリークすなわひゾンビープロセス状態になりやすく、何度かCtrl+Cしてしまうと、ファイルロックがかかってしまうから、溜まってきたら「タスクマネージャーから強制終了」しなければいけない。
裏を返せば、スクリプト実行中に１つのEXCELのインスタンスを使いまわして、EXCELファイルをCSVファイルに変換させれば、動作が非常に速くなるハズなので、xls2csv.batの中でカレントディレクトリィのxlsファイルを検索して全部csvに変換してしまった方がいい。
もし複数のシートがあるなら、book.Worksheets.Countの分だけループしてbook.Worksheets.Item(i).Nameでシート名を取り出して、「XLSファイル名＿シート名.csv」とシートごとにＣＳＶファイルを作るように改造してみたところ意外と速くなった。しかも使い方はＸＬＳファイルを放り込んだフォルダに改造したXlsToCsvS.batをコピり、そのフォルダでＢＡＴファイルをダブルクリックするだけととてもお手軽。変換中はコマンドプロンプトの画面が出るし終われば勝手に消えるので、後は予想通りの数だけＣＳＶファイルが出来ていればＯＫだ。
ただ、XLSファイルは白紙で作ると、Sheet1 Sheet2 Sheet3 の３シートができるので、そのままでは余分なSheet2 とSheet3のファイルが出来てしまうから、空のシートは省く仕組みも考えた方がいいと思うけど、
var SheetCount = book.Worksheets.Count;
if ( SheetCount ==3 && book.Worksheets.Item(1).Name=="Sheet1" && && book.Worksheets.Item(1).Name=="Sheet1" && && book.Worksheets.Item(1).Name=="Sheet1" ) {
SheetCount=1;
}
for ( var i=1; i <=SheetCount;i++) {
book.Worksheets(i).Activate();
book.SaveAs(outfile + "＿" + book.Worksheets.Item(1).Name + ".csv", xlCSV); }
程度しか思いつかないので、改造ソースは公開できるレベルに達してはいない。
とりあえず、WindowsPowerShell や Windows Script Host も あるけれど、デバッグしだすと大変だから、最初からログファイル出力やイベントビュワー出力を付けといた方がいい。
Silverlight や WPF の様に デモ専用の見かけ倒しで、見せかけの拡張性と、実用性の低さが目立つシロモノばかり出てくるから
やっぱり
MSは人の邪魔しかしない。
なのは定説ですね。
だって、便利にしたら Visual Studio が売れないもんね！
Node.jsのノンブロッキング嗜好なんてまだカワイイ。