2009.01

XFile はファイル操作（移動/削除、属性の取得などなど）に統一的なオブジェクト指向インターフェースを与えるAppleScript モジュールです。

前面のアプリケーションで開いているファイルの名前を変更する AppleScript です。Finder が最前面のアプリケーションの場合は Finder で選択されている項目の名前を変更します。

Cocoa アプリケーションで開いているファイルを処理する時にエラーがが発生する不具合を修正しました。

StationeryPalette は、パレットから選択されたテンプレート（ひな形）をコピーする事により新規書類を作成するアプリケーションです。アプリケーションに依存せず、すべてのアプリケーションのテンプレートを統一的に管理することができます。

また、新規ファイルを作る際に保存場所も決定されるので、狭苦しいファイル保存ダイアログを使う必要がなくなります。色んなアプリケーションの空ファイルを登録して、書類生成のスタートポイントとして使うと非常に快適です。

Mac OS 10.5 の Spaces を使っているときの振る舞いを改善しました。StationeryPalette はすべての操作スペースで同じように表示されます。

ところで、どなたかこのアプリケーションにアイコンを作っていただけないでしょうか

• UnixScriptsTools for mi
  • Leopard 対応版の更なる改良が終了した、マニュアルを書き直して公開するのみ。
• MergePDF
  • いまさらながら、Mac OS X 10.5 で全く動かないことに気づいた。
  • 今のやり方だと、対応させるのが難しい。Acrobat で AppleScript から JavaScript が駆動できないみたい。
  • Acrobat への依存を無くすしか道がなさそうだけど、それには時間がかかりそうだな。
  • でも、フィードバックないし誰も使っていないみたいだからもういいか？

公開しているほとんどのソフトは Leopard への対応を完了したと思う。懸案事項は・・・

• UnixScriptsTools for mi
  • Leopard 対応 version は、β版を公開しただけで、マニュアルを書き直しての正式版はまだ公開していない。
  • 僕としては最も活用しており有用なソフトの一つだと思っているのだけど、フィードバックが皆無なのでどうしたものかと思っている。
• FilterScripts for mi
  • フィードバックないし、最近自分でも使っていないからお蔵入りするかも。
• Numbering It
  • mgrep OSX が Leopard で動かなくなっちゃったから、自分で正規表現のスクリプティング機能追加を作ろうかと思っているけど、モチベーションが上がらない。
• MergePDF
  • Acrobat に依存しないようにしたいと思っている。Mac OS X 10.4 の時に一度試みたけど、PDF Kit の機能不足でかなわなかった。Mac OS X 10.5 ならできるはずだけど、これまたモチベーションしだい。
• QuickDMG
  • ディスクイメージの解凍、変換機能をつけたいけど、どうしたものか。

最前面のアプリケーションで開いているファイルを、添付ファイルとした新規メッセージを Mail.app で作成する AppleScript です。スクリプトメニューに登録して使ってください。

Finder や Mail にアプリケーションを切り替えることなく、編集しているファイルを前面に置いたまま、ダイレクトに新規メッセージを作り始めることができます。

Mac OS X に含まれているメールソフト Mai.app で、アカウント（送信元のメールアドレス）と署名を指定して新規メッセージを作る AppleScript です。

アカウントを指定してメッセージを作成するので、間違った送信元のアドレスでメッセージを送ってしまうトラブルを避けることができます。また、メッセージに含める署名もあわせて選ぶことができます。

スクリプトメニューなどに登録して使ってください。実行すると次のようなダイアログが表示されます。

前面のアプリケーションで開いているファイルを閉じてゴミ箱に捨てる AppleScript です。スクリプトメニューなどに登録して実行してください。

アプリケーションで開いているファイルをゴミ箱に入れたくなることは、ときどきありますよね。例えば、Web からダウンロードしてきた PDF ファイルが見当違いのものであったとか、文書/コードを書き始めてやっぱやめたと思ったときとか。

Finder でそのファイルが表示されていればいいですが、そうでなかったら次のようなステップを踏むことになると思います。

1. 書類ウインドウのプロキシアイコンを使って、Finder でファイルを表示させる。このとき、アプリケーションが Finder に切り替わる。
2. 書類を開いているアプリケーションに戻って、ファイルを閉じる。
3. Finder にもどって、閉じたファイルをゴミ箱にいれる。

Trash It は上記の手順を一発で行います。

最前面の書類を対象にしますから、バッククグラウンドで実行しなければなりません。例えば、スクリプトメニューから実行するとか、なんらかのランチャーユーティリティ（DragThing とか）に登録してショットカットキーを割り当てて実行するなどしてください。

Quicksilver で実行するのが一番おすすめです。ただし、バックグラウンドで実行する為に「Show icon in dock」のオプションをオフにしてください。

QuickFileType はファイルのクリエータコードとタイプコードを表示/編集するアプリケーションです。もっぱら、ファイルのアプリケーションへの関連付けを変更するのに用います。

Finder の情報ウインドウでファイルを開くアプリケーションの関連付けを変更するのではなく、QuickFileType を使ってアプリケーションとの関連付けを変更したほうがいいよ。

だれか、カスタムアイコンをお願いします。

Mac OS X でファイルを開くアプリケーションが決定される仕組みを長々と説明してきたけど、それをフローチャートにまとめてみた。

改めて眺めてみても、なんと複雑なことか。個人的には、usro リソースと UTI がクリエータコードを無視するオプションはいらないと思う。しかも、これらは一度設定されると元に戻す標準的な方法が無いからね（しつこいようだけど、次の QuickFileType を使えば戻せる）。

Finder の情報ウインドウで「このアプリケーションで開く:」を変更したときは、usro リソースを書き込むのではなく、クリエータコードを設定すればいいのにと思う。もちろん、クリエータコードを持つアプリケーションにしか関連づけられなくて、usro リソースのように何でもありという状況にはならないけど、それでいいじゃないかと思う。たまに、特殊なアプリケーションでファイルを開きたいときは、ドラッグ＆ドロップとかでいいでしょう？

そして、「すべてを変更...」をしたときは、クリエータコードを無視するオプションを設定するのはやめてもらいたい。だって、後戻りできないんだもん。UTI のデフォルトアプリケーションを変更するだけでいいじゃないか。

というわけで、Finder の情報ウインドウでアプリケーションの関連づけを変更するのはやめた方がいいです。ぜひ、QuickFileType を使ってください。

前回からちょっと間が空いたけど、さらにクリエータとタイプコードとファイルのアプリケーションの関連付けの仕組みの解説を続けたい。長いですね。それぐらい、Mac OS X の仕組みは複雑なんです。

復習すると・・・

• ファイルのデータの種類を UTI (Uniform Type Identifier) といいます。
• UTI は、拡張子とタイプコードで決定されます。拡張子が優先されます。
• UTI に対してデフォルトアプリケーションが設定できます。
• クリエータコードが設定されていると、デフォルトアプリケーションに優先します。
• QuickFileType はクリエータコードとタイプコードを自由に設定できます。
• でも、UTI に対してクリエータコードを無視するように設定されることがあります。
• クリエータコードを再度有効にする標準的手段は提供されていません。
• 次の QuickFileType はクリエータコードを無視するように設定された UTI の設定を変更して、クリエータコードを有効にできます。

Mac OS X には、さらにもう一つファイルとアプリケーションの関連付けを行う仕組みがある。Finder の情報ウインドウで「このアプリケーションで開く : 」のアプリケーションを設定したときだ。但し「すべてを変更...」を実行しない場合。

この操作で何が起こるかというと、そのファイルのリソースフォークに usro リソースとしてアプリケーションのファイルパスが書き込まれる。「アプリケーションへのファイルパス」だよ！！。すさまじく Mac OS らしからぬ振る舞いだ。なぜかって、もしアプリケーションの場所を移動したら、その関連付けはブチぎれちゃうんだぜ！！Mac OS X のアプリケーションは、インストーラを使わず、コピーするだけでインストール完了というのが理想だよね。すると、アプリケーションの場所は自由に動かしていいということだよね。でも、動かしちゃダメなんだぜ！！

アプリケーションをアップデートしたらアプリケーションのファイル名が変わっちゃうことがあるよね。すると、やっぱりアプリケーションの関連付けは切れてしまう。この仕組みはクリエータコードとか UTI のデフォルトアプリケーションとか他の仕組みに優先してアプリケーションの関連付けに使われる。usro リソースを削除するには、Finder の情報ウインドウで「すべてを変更...」を実行するしか無い。次のバーションの QuickFileType は、こんな困った usro リソースを除去することができるよ。

そして、こんな仕組みを導入しちゃったら仕様がないけど、良くないのは usro リソースと一緒にそのアプリケーションの書類のカスタムアイコンも一緒にはりつけられちゃうことだ。普通、Mac OS のファイルのアイコンはクリエータコード/タイプコード/UTI に従って動的に適切なものが表示される。でも、そういう仕組みをいっさいすっ飛ばしてアプリケーションを関連づけるものだから、カスタムアイコンを貼付ける以外に、ファイルのアイコンを関連づけられたアプリケーションの書類にする方法はないよな。

カスタムアイコンだから自動的にアップデートされることはない。関連づけられたアプリケーションの場所を動かすと、関連付けは壊れて、ファイルの見た目と実際に開かれるアプリケーションは一致しなくなってしまう。

次のバージョンの QuickFileType は、usro リソースと一緒にカスタムアイコンも消去できるよ。

つづく・・・

Pref Setter は、Preferences フォルダの中身のproperty list ファイルを一元的にブラウズ/検索して編集できるソフト。

やってくれることは、Preferences フォルダを開いて、Property List Editor でファイルを開くのとあんまり変わらないのだけど、アプリケーションの開発中はよくやることなので、専用のソフトがあると何かと効率的。そして、インターフェースが美しい。という訳で寄付した。

皆様から頂いた寄付はこのように使わせていただいております。

次の QuickFileType の実装がだいたい終了したぜ。

クリエータを無視する要素を持つファイルに対してクリエータを適用しようとすると、次のようにシートダイアログを表示してクリエータを有効にするように促すぜ。ご意見頂ければ幸いです。

もう少しテストしてマニュアルの更新したら公開するつもり、でもこれから腰が重くなるんだよな。

ご評価いただけるなら、寄付をお願いします。もしくは、カスタムアイコン作ってください。どうかよろしくお願いします。

ヘルプビューアで検索を実行する AppleScript です。指定した語句を、ヘルプビューアに登録されているすべての Help Book から検索します。QuickSilver の Action としても使用することができます。

wakaba さんが非常に美しいアイコンを作ってくれました。誠にありがとうございます。

ちなみに、wakaba さんのサイト「わかばマークのMacの備忘録」では、色んなソフトのちょー詳しい使い方や Mac OS X の Tips などが紹介されています。 とくにQuickSilver の解説に関しては他に類を見ないディープさです。自分も時々お世話になります。訪れたことのない人はぜひ一度のぞいてみることをおすすめします。

PowerSelect は選択されているフォルダの中から、条件にマッチしたファイルを検索します。それらのすべて、もしくは一部だけ選択できます。

wakaba さんが非常に美しいアイコンを作ってくれました。誠にありがとうございます。

他の変更点として、Sparkle フレームワークを使って、セルフアップデートできるようにしました。

さて、Mac OS X でファイルの拡張子はどのような意味を持っているかというと、ファイルの中のデータの種類として解釈される。したがってタイプコードと意味的にはかぶる。ファイルにタイプコードと拡張子の両方がある場合は、拡張子が優先される。つまりタイプコードは拡張子が無いときしか意味が無い。そして（実質的に）拡張子に対してデフォルトアプリケーションを設定することができる。でもちょっと正確じゃないので詳しくは追々説明する。ファイルがクリエータコードを持っている場合は、そのアプリケーションがデフォルトアプリケーションに優先して使用される。でも、クリエータコードがあっても無視される場合があるので、それについては追々説明する。

拡張子は同じデータの種類に対して複数のバリエーションがあったりする。たとえば、JPEG 画像ファイルに対して ".jpg" とか ".jpeg" とか。だから、拡張子に直接デフォルトアプリケーションを関連づけるのではなく、データの種類にたいしてアプリケーションを関連づけるのがスマートである。すると、データの種類に対して公式名称が必要になる。それを、Uniform Type Indentifier (UTI)といい Mac OS X 10.4 から導入されている。例えば、JPEG 画像なら "public.jpeg" 、HTML データなら "public.html" という名称が与えられている。ファイルは拡張子やタイプコードによって UTI に関連づけられている。そして、UTI に対してデフォルトアプリケーションが設定することができる。すると当然、拡張子やタイプコードと UTI の変換テーブルが必要になるのだけど、一般的によく使われる UTI に関してはシステムで定義されている。特定のアプリケーション固有のデータもあるわけで、それ対する UTI はアプリケーションバンドルの中で定義されている。

UTI に対するデフォルトアプリケーションを変更するには、Finder の情報ウインドウで「このアプリケーションで開く」でアプリケーションを設定し、「すべてを変更」を行えば良い。この操作を行っても本来はクリエータコードは UTI に優先してアプリケーションの決定に使われるべきなのだけどでも、クリエータコードが無視されてしまうようになってしまうことがある。それは、クリエータコードを持っているファイルに対して、上記のアプリケーションの変更操作（「このアプリケーションで開く」を変更して、「すべを変更」を行う）を行ったときだ。これを行うと、その UTI に関してクリエータコードを無視するという設定がシステムに登録される。ちなみに、クリエータコードを無視するオプションを変更する標準的な手段は提供されていない。クリエータコードを再度有効にする為には、「ホームフォルダ/ライブラリ/Preferneces/LauncheServices.plist」を直接編集するか、消去してから再起動するしかない。

ある UTI に対してクリエータコードを無視するかしないかを設定する API は、ちゃんと公開されているので、適切なアプリケーションを作れば LauncheServices.plist を消去するなどしなくても、クリエータコードを再度有効にできる。ということを次の QuickFileType でできるようにする予定。

つづく・・・

昔から Mac を使っている人に取っては釈迦に説法なのだけど、クリエータコードとタイプコードについてレビューしてみたい。とくに、Mac OS X になってから Mac を使い始めた人に取っては、何それ？という、人は少なくないのではないかと思う。他に知っている人がいっぱいいそうなことを説明するのは気恥ずかしい気がするけど、QuikcFileType を近々更新するので、その効用を理解していただける人を増やしたいと思って少々雑談しようと思う。

クリエータコードとタイプコードは、Mac OS 固有のファイルの属性だ。ファイルの変更日付みたいな感じでファイルシステム上でファイルにつけられているおまけ情報だ。4文字のアスキー文字で表現されてる。たとえば、"MACS" とか "TEXT" とか。昔は、クリエータタイプとファイルタイプと呼ばれていた気がするけど、最近の開発者向けドキュメントではクリエータコードとタイプコードと記述されているのでそう呼ぶことにする。

何の役たっているのかというと、クリエータコードはファイルをダブルクリックした時にどのアプリケーションで開かれるかを決定するのに使われている。ファイルと同じクリエータコードを持つアプリケーションを OS が探して、そのアプリケーションでファイルを開いてくれるという仕組みになっている。タイプコードはファイルの中身のデータの種類を表していて、アプリケーション側でそのファイルをどう処理するか決定するのに使われる。ここまではMac OS 9 以前の話で、 Mac OS X ではファイルとアプリケーションの関連付けは非常にややこしいく色んな仕組みが使われている。この辺は追々説明しようと思う。

Windows とか Linux とか、他のプラットフォームではアプリケーションとファイルの関連付けには拡張子だけが使われているよね。これだと、同じ拡張子を持つファイルだと常に同じアプリケーションで開くようになっちゃう。例えば、ある HTML ファイルはブラウザで開きたいけど、別の HTML ファイルはエディタで開きたい、ということができない。Mac OS では、クリエータコードを適切に設定すれば普通にできる。こういう仕組みが、大昔から Mac OS の他のプラットフォームに対する優位性として上げられている。

ご存知の通り、Mac OS X ではファイルの拡張子もアプリケーションの関連付けに関与している。Mac OS 9 以前は、拡張子はアプリケーションの関連付けには全く関与していなくて、拡張子が無いファイル名のファイルなんて普通だった。しかし、インターネット全盛のご時世、他のプラットフォームとファイルを交換するのが当たり前になったものだから、拡張子ないと困ったことになってしまう。クリエータコードとタイプコードは Mac OS 固有のファイル属性だから、他のプラットフォームに持っていった時にそれらの情報は失われる。そして拡張子が無いと何のファイルか分からん！ということになる。さらに、昔話になるけど、一方で Mac OS 使っている本人には、クリエータコードとタイプコードが無い拡張子付きのファイルを持ってきてもらってもいっこうに不便が無かった。というのも、ファイルをダウンロードしたり、Windows フォーマットのディスクをマウントしたりしたとき、ファイルの拡張子にしたがってクリエータコードとタイプコードを自動的に割り当てる仕組みが Mac OS にあったんだ。確か、FileExchange とか言う名前の技術だったと思うけど、まあ今となってはあんまり関係ない話だ。

つづく・・・・

現在、QuickFileType を鋭意オーバーホール中です。Leopard に移行したのを機会に見直してみるといろいろバグや改良すべき点が見つかった。

ちなみに、QuickFileType は、ファイルのクリエータコードとタイプコードを設定するアプリケーションです。拡張子とは独立に、ファイルごとにファイルを開くアプリケーションを設定できます。また、現在のバージョンでも Leopard 特有の不具合は無いです。

今の改良プランは・・・

• バグフィックス
  • 細かくいろいろあるけど、一番大きなミスは「クリエータを無視する」の表示が全く機能していなかったこと。
• 機能追加
  • Sparkle フレームワークを採用してセルフアップデートできるようにする。
  • ささやかだけど重要だと思うのは、クリエータを無視するように設定された UTI を、クリエータを優先するように（通常の動作）戻せる機能を付けたこと。
    • これをやってくれるユーティリティーは見たこと無いけど、どんなものだろう。
  • usro リソースの削除機能
    • これも、クリエータコードが無視される原因になる。Mac OS X の汚点の一つだ。

このように、クリエータコードをきっちり活かすように頑張っている。どんなものだろう。もし評価してくれるなら寄付ください。もしくは、カスタムアイコン作ってください。どうかお願いします。

クリップボードの中のスタイル付きテキストからスタイル情報（フォント、色、サイズなど）を取り除き、プレインテキストに変換します。

ワープロ等にテキストをペーストする時にプレインテキストに変換してから行うと、ペースト位置でのスタイル情報に従って貼付けることができます。

いまさらの、Leopard 対応版です。

Leopard では、AppleScript から文字列をクリップボードに挿入すると、有無を言わさず適当なスタイル情報が付け加わっちゃうみたい。仕様がないので、シェルコマンド pbpaste/pbcopy を使って、クリップボードの内容をいじることにした。不細工な実装だけど、しょうがない。

最前面の Finder ウィンドウを、アイコン表示にしてアイコンのサイズの最大(128×128)に変更します。画像ファイルをプレビューするのに便利です。

Terminal.app の新しいターミナルウィンドウを開くコマンドラインツールです。ターミナルで、「newterm」を実行すると、現在の working directory と同じ working directory のターミナルウィンドウが新たに作られます。

いまさら、Leopard 対応。

Leopard 対応するだけで、大騒ぎです。数が多すぎるんだよね。公開している作品がすべて Leopard に対応する前に次の OS がやってきそうな気がする。

最前面のコンテキストに対応した working directory をターミナルで開きます。

• 最前面のアプリケーションが Finder である場合、Finder で選択されている場所を working directory としたターミナルを開きます。
• 最前面に何らかのファイルを開いているアプリケーションがある場合、そのファイルがある場所を working directory としたファイルを開きます。

いまさら、Leopard 対応版です。

Finder で選択されている場所をターミナルで開くユーティリティは数多くありますが、Open in Terminal はそれらとは一味違う。たとえば、なんらかのエディタでシェルスクリプトを書いていたとする。ターミナルでそのスクリプトを実行したな〜と思ったら、そのファイルがあるフォルダをすぐさまターミナルで開くことができます。いちいち Finder に戻る必要は無いのがスマート。

このようなことをする為には、Open in Terminal をバックグラウンドで実行する必要があります。スクリプトメニューや Quicksilver などから実行してください。

今、MacOS X 10.5.6 のターミナルのバグに一つ気付いた。

例えば、次のような AppleScript で最前面のターミナルの設定を変更したとする。

そして、別の設定セットのターミナルウィンドウに切り替えてから、もとのターミナルに戻ってみると、そのターミナルウィンドウの設定セットの値に強制的に戻っちゃうぜ。normal text color だけでなく、試した限りではターミナル個別に変更した属性は全部無効になっちゃうぜ。幸いなことに、TerminalControl で設定したカスタムタイトルは難を逃れているようだ。

つまり、複数の設定セットが混在した状況では、AppleScript を使ってのターミナルウィンドウのカスタマイズは役に立たないということです。ターミナルウィンドウの属性はすべて設定セット経由で管理しろということか。それはそれでスマートな気もするが、不自由な気もする。

追記 2009-01-27

この現象が発生するのは、インスペクタウインドウが表示されている時だけであることに気付きました。

ターミナルでのシェルコマンドの実行を支援するモジュールです。以下のような、複雑な処理を行いたいときにこのスクリプトはお役に立てるでしょう。

• ターミナルウィンドウを追跡して、同じターミナルで何度もシェルコマンドを実行したい。
• シェルコマンドの終了を待ってから、次の処理に移りたい。
• シェルコマンドを実行するターミナルのシェルを指定したい。
• ターミナルウィンドウの、色の設定、タイトルの設定、もしくは設定セットを指定したい。

いまさらながら、Leopard 対応版。

TerminalControl.osax は Mac OS X 10.5 の ターミナル.app の 足りない AppleScript に関する機能を補うスクリプティング機能追加です。通常の ターミナル.app と AppleScript ではできない、以下のことを可能にします。

• ウインドウ/タブのカスタムタイトルを個別に変更
• ウインドウの背景色の透明度を設定

今回のバージョンでは、背景色を透明度を含めて設定できるコマンドを付け加えました。いらんかな〜と思っていたけど、Tiger でできていたことが、Leopard でできなくなったのはしゃくだったので作っちゃいました。

ライブラリ/モジュールとしての AppleScript のリファレンスマニュアルを生成するアプリケーションです。

ソースコードにかかれたコメントから、スクリプトのリファレンスマニュアルを HTML として出力します。バンドル形式のスクリプトの場合、バンドル内に(ヘルブビューアに表示する) Help Book としてリファレンスマニュアルをセットアップできます。

Sparkle フレームワークを使って、セルフアップデートできるようにしました。当然、ご利益があるのは次のアップデートからですが。

これに伴い、ソースコードは別のパッケージに分離しました。

pbcopy と pbpaste で UTF-8 入出力させる為に、次のように、環境変数 __CF_USER_TEXT_ENCODING を設定すると良いよ。というのを何度かご紹介しました。

export __CF_USER_TEXT_ENCODING=${__CF_USER_TEXT_ENCODING/:*:/:0x08000100:}

僕は、これを .bash_profile に書き込んでいたのだけど、これをやっちゃうと osascript がうまく動かないことに気付きました。

というわけで、環境変数を勝手に変えちゃいかんということのようなので、pbcopy/pbpaste で UTF-8 のテキストを扱えるようにラッパースクリプトを書くことにしました。

まずは、pbcopy のラッパー upbcopy。

次に、pbpaste のラッパー upbpaste。Unicode の LINE SEPARATOR を LF に変換する為に、perl を使っている。

寄付ありがとうございました。

忌憚の無いご意見を頂けることを願ってやみません。

41 人目

AppleScriptHTML がお眼鏡にかなったことを光栄に感じます。

今後も、忌憚の無いご意見を頂ければ幸いです。

40 人目