製品に組み込まれたモジュールとマニュアルで通信する方法を調査していたのだが、
有識者に聞いたら、正攻法でやる方法はないという返答が返ってきて、うーん。
その後、いろいろな資料を調査した結果、システムを停止させて、特定の機能だけ動作する状態にした上で、
メンテナンスツールを使って、内部レジスタに読み書きするという方法でできることが確認できた。
とりあえずこれで最低限の実験は出来たのだが、レジスタの読み書き1つずつを手操作で行うのは大変だ。
これらの操作はWindowsのコマンドライン上で動くメンテナンスツールを操作するので、
操作をまとめてバッチファイルにすればよさそうなのだが……
- レジスタへの書き込み操作はメンテナンスツール上のプロンプトにデータを入力する必要がある
- レジスタのリード結果の表示が冗長なので整形が必要
ということで何らかの工夫が必要そう。
そこで共有ディレクトリを検索していたら、JScriptで書かれたスクリプトが出てきた。
目的は違うのだが、同メンテナンスツールを使って、レジスタの読み書きを行うという点では共通している。
これを見てみるとレジスタへの書き込みは、データをパイプで標準入力から入力してやっていた。
ご存じの方もおられるだろうけど、プログラムには標準入力(stdin), 標準出力(stdout), 標準エラー出力(stdout) がある。
通常は、stdout, stderrはコンソール画面に、stdinはキーボードに繋がれている。
これをつなぎ替えて、stdoutをファイルに出力したり、他のプログラムのstdinに繋いだり出来る。
stdoutを他のプログラムのstdinにつなぐ方法をパイプといい、これで書き込みデータを送り込んでいたのだ。
さらに出力データの整形も行っており、かなり参考になった。
ところでJScriptってなんやねんと。JavaScriptのMicrosoftの呼び名といえばそうなのだが……
ただ、それ以上に重要なのが、これがWindows Script Host(WSH)で動くスクリプトであることだ。
WSHはJScriptまたはVisual Basic Script(VBS)で記述されたスクリプトを実行することができ、Windowsの各種機能へのアクセスができる。
コマンド実行、ファイル入出力、レジストリアクセス、そしてJScriptが標準的に備えている文字列処理などを使うことができる。
単純なバッチファイルではできない操作をJScriptに記述して、それを呼び出すバッチファイルを作るような使い方をしていた。
cscript //nologo fooexec.js param1 param2
これでマニュアル通信に必要な操作をJScriptで一括して実行できるようになったわけだけど、なんとなく使いにくい。
それでいろいろ調べていたが、Windows 7以降だとWindows PowerShellが標準搭載されるようになったので、
WSHよりもこちらを使った方がよさそうだとわかった。PowerShellはWSHの事実上の後継となっているようだし。
PowerShellの特徴は .NET Frameworkベースで、.NETのオブジェクトを取り扱うことができるということ。
その上でスクリプト言語としての特徴を備えており、PowerShell専用のコマンドレットを多数備えている。
ところが実際にPowerShellを使ってみて思ったのは「なんてめんどくさい!」ということ。
というのも、コマンドを実行して、標準入力をPowerShellから入れる、ということを書こうとすると、
.NET Frameworkのオブジェクトを直接操作する必要があり、ほとんどC#のプログラムを書いているような感じ。
PowerShellの名に違わぬパワフルさだが、スクリプト言語としてはどうなの? という感じ。
記法も独特で、制御構文はC#っぽいけど、改行の記述方法が “`n” だったり、比較演算子が –lt, –eq だったり。
外面はとっつきやすそうだが、なんでこうなるんだよ、というのが続出するのがPowerShellという感じ。
あと、PowerShellは再利用性も高くて、簡単に他のスクリプトを読み込める。
. .\foolib.ps1
これだけで foolib.ps1 というPowerShellスクリプトを読み込める。(PowerShellのスクリプトは拡張子ps1を使うのが通例とのこと)
これでスクリプト内で定義した関数を再利用できるわけだ。
ところが、初期状態のPowerShellでこのコマンドを実行すると失敗する。
というのも初期設定ではPowerShellは一切のスクリプトの読み込みができない。安全性を考慮してのことらしいが。
なんでそんな厳しいの? と思ったのだが、WSHがセキュリティ上の問題を引き起こしてきた反省らしい。
PowerShell / about_Execution_Policies (Microsoft)
1回設定すれば以後は大丈夫なんだけどね。
LinuxだったらPerlで書いたんだろうけどなぁ。
そもそもUNIX系のOSでは、シェルスクリプトがそれなりに強力だ。
シェルスクリプトでawkとかsedのような文字列処理コマンドを補助的に呼び出して使うこともよく行われてきたようだ。
そして、Perlのようなスクリプト言語の活用もよく行われていた。
Perlはシェルスクリプト内などで補助的に使われることもあるけど。ワンライナーで使っても強力なので。
今どきはPerlというよりPythonなのかなという気はするけど、僕はPerlで慣れてるからPerlを使うかなと。
いずれにせよLinuxならば、標準で使えるものですから。
Windowsでも別途インストールすれば、他のスクリプト言語も使えるんですけどね。
職場でもActive Perlを入れて使ってる人もいるようだけど。今どきActive Perlかよって思うけど。
でもやっぱり標準で入ってる方がよいわけで、これまでWSHで動くJScriptまたはVBSが重用されてきたのもそういうことでしょう。
今後は PowerShell がこの立ち位置になるということだろう。
確かにPowerShellにできないことはないなと思った。書きやすいかはさておき。
全体的にWSHより素性がよいのは間違いないので、乗り換えて行こうとは思ったけど。