WSHを始めよう @IT

連載開始記念。

WSH は面倒だ。それは WSH 自身は自動化するための道具じゃないから。WSH は単にスクリプト言語と OS を多少仲良くさせるための土台でしかない。

WSH は面倒だ。tips ばかりで体系的な資料が少ない。まるで Web 上に散見される Linux セットアップ情報と同じだ。

WSH は面倒だ。スクリプト言語は結構いろんなものが選べるはずなのに、ほとんどのサンプルは VBScript で、Un*x 系の人間にとって悪夢みたいなものだから。¹

WSH は面倒だ。実は WSH のインターフェイスだけではできないことが多い。例えばファイルアクセス。これは WSH では提供されていない。WSH とはまた異なるライブラリである FileSystemObject を使うんだ。びっくりだろう？

WSH は面倒だ。実は WSH のインターフェイスだけではできないことが多い。WMI とか ADSI とか CDO とか知らないと結局外部コマンド頼みだ。しかも標準で用意されている外部コマンドではできないこともまた多いんだ。

WSH は面倒だ。WMI や ADSI に関しては WSH よりぐっと情報が少ない。オブジェクトの定義を示した英語のリファレンスは存在するので、それを読んで「こうかな？」とコードを組み立てていく必要がある。

WSH は面倒だ。ってゆーか WMI で出てくる奇妙なおまじないや WQL？ってゆーの？ あれがキモイ。<> とか BASIC 風なのはゲイツの呪いかとか思っちゃう。Windows に触る限り BASIC 文化からは逃れられないってか。

WSH は面倒だ。CDO に至ってはもはや現行の資料があるんだかどうだかあやしいレベルだ。WSH と CDO を使ってメールを送信するサンプルスクリプトはいくつか見つかるが、じゃあ CDO では他に何ができるのか、教えてくれるサイトは Microsoft を含めてないに等しい。²

WSH は面倒だ。なぜなら提供されるライブラリが「機能するコマンド」ではないから。これらはあくまでプログラマが扱うオブジェクトなんだ。OS が持ってる情報を、多少スクリプトからも利用しやすいようにラップしただけなんだもの。プログラミングが得意な人ならともかく、管理コストを下げたいだけの人に対してはハードルが高いと言わざるを得ない。たぶん Visual WSH Studio なんつー製品が出る日も近い。

連載への期待と自身が WSH へ感じた落胆をミックスしてネタにしてみた。

基本的に Windows の管理の自動化は Unix の管理の自動化より面倒だと思う。標準で揃ってる道具に違いがありすぎる。log の rotate 一つサクっとできないだけで十分にいやな思いを満喫できるってもんだ。スクリプトに関しては MSH³ ベースになったら多少面白いかなとは思うんだけど⁴、そうするとまたイチからノウハウの溜め直し。この「以前のノウハウが死んでしまうことがやたら多い」のも管理する側からすると Windows の決定的にダメなところ。新機能が嬉しいなんて思うのは営業と広告記事書く人と何も分からずにお金だす人だけ。管理する人間にとっては同じノウハウが長い間通用して安定して動くことの方が何倍も嬉しい。

あと MSH/Windows PowerShell が .NET Framework 前提なのは旧世代の人間からすると嬉しくないですな。そんな追加追加でやっていいなら ActivePerl 入れてゴリゴリやっちゃうよと思ってしまう。だってその方が Windows 独自の話に悩まなくてよくなる部分が増えてハッピーだもの。

ちゅーことでスクリプトについては Vista に期待ってことで(え

※ おめーはこんな情報も押さえてねーのか、ってツッコミは大歓迎です。

参考

アサマシも含めて手元の資料を吐き出しておく。

• システム管理な雑記 – Sleeve notes of a sysadmin –
  • Windows管理周辺の情報はまずここから。ただしスクリプティングそのものは得意でないらしい。

WSH

• Windows管理者のためのWindows Script Host入門 (@IT)
• Windows Script (microsoft.com/japan)
  • WSHエンジンとかドキュメントとか
• Welcome to the Script Center (microsoft.com)

microsoft のサイトはできるだけ英語の方を探した方がよい。日本語版は訳が追いついてなくて結構な数のページが存在しない。あと、CHM ファイルに関するグチはこの資料を見てて感じたものです。絶対使いにくいって！

WMI & ADSI

• WMI Reference
• WMI Query Analyzer

• Active Directory Service Interfaces
• Active Directory Service Interfaces Reference
  • この中の System Providers ってのが大事
  • ADSI WinNT Provider
    • アカウントとか操作するのは実は WMI よりこっちの方が楽

Scriptomatic っていうツールがあるんですが、要するにただのサンプル閲覧環境ってだけで別に嬉しくなかった。なんかすげー絶賛されてたりするんだけど、なんでか分からん。まぁオフラインでも WMI とか ADSI 使ったスクリプトの開発ができますよってことか？

CDO つか Messaging

• Windows標準機能とWSHを使ってメールを送信する (@IT : Windows TIPS)
• WSH(JScript)でメールを送信する - Weboo! Returns.
• CDO を使用して送信メールにファイルを添付するにはどうすればよいでしょうか。 (Hey, Scripting Guy !)
• MSDN Home > MSDN Library > Win32 and COM Development > Messaging and Collaboration

自由度を求めるなら CDO は使わずに Command Line SMTP Mailer for Windows や XMail Home Page (日本語) や ＢＳＥＮＤＭ ＥＸＥ などなどの SMTP クライアント（サーバ）を自前で用意した方がたぶん確実で早い。余計なものを入れたくない気持ちは分かるが、標準状態の Windows はつらすぎる。

※ しまった。タイトルは「あなたが WSH を使うべきでない10の理由」にするんだった！

ついていけてなかった。

auのEメールアドレスが相互接続性を保障できないルールに変更? (/.-j)

これはあれじゃないすか。

docomo が Compact HTML のときみたいに標準化へ向けたアクションを取る

のがいちばんじゃないかな。もはや世界最大のプロバイダなんだから影響力絶大でしょ。実験したところ、メジャーな MTA で問題が起きないって話もあるんだし。その方が現実的ではないかと。

それにこういう MUA 側の対応についての話題が大きくなれば、Outlook Express の添付ファイルの問題なんかももう少し真面目に考えなきゃなって機運になるんじゃなかろうか。

いずれにしても MTA, MUA の実装と RFC の乖離はあまり進まない方がいいと思うので、RFC改訂に一票。