タイトルBrowsing Mac OS X》AppleScriptはどうなんでしょうか?カテゴリーAppleScript, Browsing Mac OS X
作成日2001/4/18 15:39:39作成者新居雅行
MacWIRE Onlineを見ていたら、魚井先生に呼び止められたような気がしたので(笑)、AppleScriptについて論じてみたい。AppleScriptは、Mac OSから存在していたシステム機能であるが、もっとも根底にあるのは、AppleEventというアプリケーション間や、あるいはシステムとアプリケーションとの間などのソフトウエア間でのやりとりを行う機能がベースになっている。たとえば、あるアプリケーションから、別のアプリケーションに対して、「データを下さい」というと、背後で通信が行われて、「はいどうぞ」とデータがもらえるというような仕組みがあるのだ。Finderで文書ファイルをナニゲにダブルクリックすると、そのとき、文書に関連づけられているアプリケーションが起動するのだが、システム側からそのアプリケーションに対して「この文書を開きなさい」という指令が投げられる。これも実はAppleEventなのである。このAppleEventのやりとりを、手順書きつまりプログラムとして記述したら、アプリケーションソフトをリモートコントロールのように、自由にプログラムで動かせる。だけど、AppleEventのデータ自体を記述するとなるとプログラム作成が大変になるので、より自然言語に近い形でプログラムを作成できるような枠組みを提供しているのがAppleScriptなのである。その一方で、単にアプリケーションのコントロールという「マクロ」的なことをするだけでは機能的に不足するので、繰り返しや条件判断といった制御構造、変数の扱いなどなど、プログラミング環境として必要な機能も備えている。また、アプリケーションに存在するデータはオブジェクト的に扱えるがオブジェクト指向プログラミングに必要な機能は揃っているわけではないので、いわば緩やかなオブジェクト指向環境でもある。なお、AppleScriptでコントロールするアプリケーションはなんでもOKではなく、AppleScriptに対応していないといけない。Finderは対応しているが、世の中すべてのソフトが対応していないのが頭の痛いところでもある。しかしながら、QuarkXPressはAppleScriptに対応したため、AppleScriptはDTPの世界では必須のソリューション提供手段となっている。また、ファイルメーカーProも対応しており、元原稿のデータベースをもとにQuarkXPressでレイアウトという事例はなかなかの見物である。(もっとも、ファイルメーカーPro5ではなぜがパフォーマンスがぐっと落ちたのが残念なところである。)

Mac OS XになってもAppleScriptは残るのだろうかという心配はずっとあったが、2000年のMacworld Tokyoに合わせてAppleの担当者が来日した時には、なくなるどころか、Mac OS Xでの重要なコンポーネントとなって、パフォーマンスも高くなり、より実用度が高くなるという話があって、大きく期待をさせた。しかしながら、Mac OS X Public Betaでは、FinderではなくDesktopになっているなどちょっと戸惑わされた。もっとも、Mac OS X 10.0になってFinderに戻ったので安心はしたが、実際にプログラミングに取りかかるものの、結論的には「待ち」に入らざるを得ない状態ではないかと思う。実は、昨日、一生懸命あるAppleScriptのプログラムを、Mac OS X環境で動かそうとした。細かい点はいっぱいいろんなことがある。まあ、それは仕方ないとして一生懸命なおしながら、あと1行に漕ぎ着けた時、ある命令にどう見ても動かないバグ(だと思う)があることが判明し、それに代替え手段を使うにはまたおおきくなおさないといけないこともあって、強く挫折感を味わったのだ。そこに来ての魚井先生の記事…これはなんか書かないといけない!
なお、AppleScriptのプログラムは、/Applications/UtilitiesにあるScript Editorで行える。Mac OS 9.1までにあった「スクリプト編集プログラム」のMac OS X版で、ほとんど機能的には同じようなものだ。32KBまでしか入力できなかったスクリプトも、それ以上のものが扱えるようになった点は進歩である。なお、編集用のフォント設定はあまりいい感じではないので、12ポイントにしたり、演算子をOsakaではなくGenevaにするなど微調整しないと見づらいだろう。

実はそれ以前に成功したスクリプトもあった。ほとんどがファイルメーカーProとファイルへの書き込みを行うようなスクリプトはほんのちょっとの修正で動くようになったのである。このスクリプトは請求書の処理とかをさせているので、ファイルメーカーProの扱いが中心であるため、スクリプトはClassicアプリケーションのまま使っている。
それではということで、原稿作成に使っている「ファイルのフルパス名をクリップボードに得る」というAppleScriptプログラムを、Carbonアプリケーションとして使ってみた。このプログラムは、システムに標準のダイアログボックスを出す命令(display dialog)を使っているのだが、日本語がことごとく文字化けするのである。自分で作ったプログラムだから、文字化けしても使えるのではあるが、その他の部分はきちんと動いているようだ。
そしてトライしたプログラムは、Finderの機能をふんだんに使うものである。状況を敢然に把握し切った状態ではないので、整理されていないがその点はお許しいただきたい。そのプログラムはいきなりのっけからエラーの連続だ。どうも、fileクラスの扱いが変なのである。たとえば、exists file "パス名"は存在するファイルのパスなのにfalseを戻す。ところが、exists alias "パス名"にすると存在するファイルならきんとtrueを戻すのである。それから、あまりいいプログラムではないのだが、file "...." as stringのようにしてパス名を文字列で得るようなことを頻繁に使っていたのだが、そこでエラーが出て止まるのである(もっともこの方法は素直な手法ではないので文句も言えないのだが…)。ただ、この点に関しては、ファイルへの参照ではなくパス文字列として扱い、ここ一番でaliasを使って参照することで、おおむね逃れることができた。なお、file "..." of folder "..." という記述が使えないわけではなく、使えば場面もある。なかなかややこしい。
それから、パッケージ化したアプリケーションの扱いはそうではないものと同じようには使えないようなのである。たとえば、TextEditのエイリアスを作るとしよう。そのエイリアスの解決先に対して、クリエイターを取得するということができないのである。また、テキストファイルをTextEditで開くために、open .... using (TextEditへの参照) のようなプログラムを作成したがエラーが出るのである。おそらく、TextEditへの参照はフォルダであると見ているのじゃないかと思われる。Contentsフォルダから入っていくなどのチェックはしていないが、そうするとパッケージかシングルバイナリかで処理をわけないといけない。どうしてもその場で動かさないといけないものでもない限り、やっぱり、システムがきちんと対応するのを待つのが筋だと考えた。
それから、「初期設定」フォルダを参照するのには、Finderの機能で「preferences folder」というプロパティ値を使うのだが、これが使えないようになっている。もちろん、よく御存じの方は「path to preferences」を使えばいいとすぐにおっしゃるだろう。だけど、筆者の作っているプログラムではこのあたりでことごとく記述をかえないといけなかった。一括置換ではだめだったというパターンだ。
いずれにしても、Finder向けのプログラムを、Mac OS Xで動かす場合には、かなり手を入れないといけないことになる。ただ、fileで機能しないでaliasで動くようなのはやはりバグと見るべきだと思われるのだが、そうした点が修正されるのを待つと言う必要も出てくるだろう。
(続く)
関連リンク