「Mac OS X実践活用ブック」追補情報 |
※ここは、拙著のMac OS X解説本「Mac OS X実践活用ブック」（技術評論社、424頁、2380円）に関するコーナーです。校正情報やよくある質問の答えなどをここでまとめて掲載します。
★校正情報★ |
※ここでは、内容に関する記述間違いや校正ミスについて整理します。もし、間違いなどを見つけた方は、どうぞ御連絡ください。ここで報告させていただきます。
※21ページ ヒラギノフォントの説明
なぜか、「モリサワの『ヒラギノ』」とありますが、皆さん御存じのように「ヒラギノ」の開発元は大日本スクリーンです。指摘されるまで、全く気がつきませんでした。ここで訂正させていただきます。
※211ページ リモートログインを開始する
235ページ コマンドで実行されるものに注意！
システム環境設定の「共有」にある、「リモートログインを開始する」は、「Telnetと呼ばれる機能を使って、外部からリモートログインできるようにするもの」と記述してあります。が、ver. 10.0.1より、利用可能なサービスはSSHのみとなり、Telnetはデフォルトでは使えないようになっています。（Telnetを使用する場合は、/etc/inetd.confファイルを直接書き換える必要があります。これは非表示ディレクトリ内にある、ルート以外に書き換えできないファイルですので、それらの扱い方がわかる人以外は「そのままでは使えない」と考えて下さい）
※233ページ 旧『書類』フォルダやX以外のシステムフォルダは保護されない！
Mac OS Xでは、Mac OS 9までの「書類」フォルダは保護されず、誰でも見られるようになってしまう、と記述してありますが、これは「管理者権限を持つ利用者なら、誰でも見ることができる」と訂正いたします。管理者権限を持たない利用者の場合、「書類」フォルダは見ることができません。（※これは２刷以降では修正されています）
※318ページ 図（ハードディスクにmach、mah.symというファイルが見える）
Machカーネル関連ファイルは、当初はMac OS Xを実行すると9.1上で見えるようになっていましたが、ver. 10.0.2以降では変更され、9.1でも見えないようになっています。
※Part 3 Chapter 2「開発環境について」補足
現在、Mac OS Xが標準バンドルされた機種が既に発売されていますが、これらの機種では、パッケージ版Mac OS Xで付属していた「Developer Tools CD」が付いていません。このため、410ページ以降の「開発ツールについて」で触れているアプリケーション類は付属していませんので了解ください。
★追補情報★ |
※本著作の内容に関する追補情報です。説明が足りないところ、追加して説明しておきたいものなどを整理していく予定です。
★ホームディレクトリのパス表記について★
本書では、 後半、ホームディレクトリ以下にあるフォルダなどを示す際に、「home/Documents/」というようにhomeという名前でホームディレクトリを示しておきました。これはわかりやすいようにということで記したのですが、UNIXの一般的な表記ではありません。従って、例えばターミナルから「cd home/Documents/」などと実行してもダメです。
ホームディレクトリは、UNIXの世界では「~」で示されます。例えば、ホームディレクトリの「Documents」フォルダに移動するならば、「cd ~/Documents/」となるわけです。本書では、ターミナルの説明は「読みたい人だけ読む」という扱いなので、わかりやすさを優先して~を使いませんでした。が、逆に混乱してしまった人もいるかも知れませんので、ここで補足しておきます。
★271頁、「Dockの使いこなし」★
ここでは、Dockの使いこなしの方針として「アプリケーションを登録するものと限定し、フォルダは他の整理法を考えよう」と提言しました。が、もしあなたが２ボタンマウスを使っているのであれば、「アプリケーションをフォルダで整理しDockに登録する」という方法があることを知っておくとよいでしょう。
Dockにフォルダを登録すると、コンテクストメニューとしてその中身が表示されるようになります。つまり、フォルダ内にアプリケーションなどがあれば、それをメニューで選んで起動できるようになるのです。ただ、通常はCtrlキー＋クリックするか、しばらくアイコンをプレスし続けないとメニューが現れないため、正直「便利！」というほどではないかも知れません。
しかし、Mac OS Xは２ボタンマウスに対応しているため、２ボタンなら、アイコンを右クリックするだけで簡単にメニューを呼び出せるのです。ですので、例えば「Applications」フォルダを登録しておけば、中にあるアプリケーションを簡単に起動できるようになります。
ただし、ファイルのドラッグ＆ドロップなどは行えないので、普段、文書の作成に使っているようなものは、やはりそれだけをDockに登録した方が便利でしょう。フォルダ登録による起動は、あまり多用しないものをまとめて登録できる、というように考えるとよいでしょう。
★361頁、「日本語の文字化けについて」★
Mailでメールの文字が化ける原因ですが、どうも掲載したコードによる問題だけではないようです。また確認方法も、本文については保存して確認できるのですが、タイトルなどが化けてしまう現象はこれではわからないこともあり、完全ではありません。
今のところ、文字化けの完全な回避方法はちょっとわからないというのが現状です。正直、早く他のメールソフトが出てくるのを待つしかない、という気もします。標準のMailはあまりに問題が多く、とても勧められません。 でも、使っていますが（笑）。
★308頁「スクリーンセーバをカスタマイズする」★
ここでは、既にあるスクリーンセーバをカスタマイズするということにとどめていますが、某誌ではモジュールのパッケージ内にあるInfo.plistを書き換えることで新しいスクリーンセーバモジュールを作れる、という記事が掲載されていたそうです。これを読んで、「掌田さんの本では新しいモジュールを作るのは我慢しよう、とあるけどなぜですか」と質問をいただきました。確かにInfo.plistを書き換えれば、モジュール名や初期設定ファイルのファイル名まで変更でき、一見すると新しいモジュールが作れるように思えます。が、実際に試した末、「新しいモジュールが作れます」という形で執筆するのはやめました。
結論からいえば、Info.plistを書き換えても、完璧に新しいモジュールは作れません。いえ、作れるのですが、ベースになったモジュールと新しいモジュールのどちらか一方（先に選んだ方）しか機能しないのです。わかりやすくいうと、システム環境設定で「スクリーンセーバ」を選び、新しく作ったモジュールを選ぶと、確かに設定できます。が、その後で、元になったモジュールを選ぶと、機能しないのです。ただし、一度システム環境設定を終了し、新たにスクリーンセーバを開くと、機能するようになります。つまり、スクリーンセーバを開くと、常に「先に使った方だけ」しか認識しないわけですね。
これは、Info.plistの中で、「NSPrincipalClass」というものによりモジュールのプログラムを識別していることに関係します。これは、モジュールの起動クラス（プログラムの最小単位みたいなもの）を指定するものです。Cocoaのプログラムはオブジェクト指向という考え方で作られており、プログラムは「クラス」と呼ばれる小さなかたまりの集合体のようになっています。そして、「このクラス名のものが起動用のクラスですよ」ということをNSPrincipalClassで指定しているのです。これは、勝手に修正することはできません。これはプログラムファイルの中にあるクラスの名前ですから、変更してしまうと、起動クラスが見つからなくなり動作しなくなってしまいます。
スクリーンセーバの環境設定では、モジュールを選択した際、このNSPrincipalClassのクラス名にて識別し起動しています。モジュールをコピーして新たにモジュールを作った場合、両者は同じクラス名になってしまい、区別がつかなくなります。このため、先に選んだ方だけが動くようになるようです。――こういうのは、「どんどん新しいモジュールが作れるよ」と紹介してよいのだろうか？と思ったのですね。まあ、確かに機能はするのですが、こういうのは個人的に非常に気持ち悪いのです。そういうことなので、これは各自の判断で考えてください。私は勧めません。
なお、.plist拡張子のファイルは、Developer Toolsがインストールしてあると、ダブルクリックで「Property Editor」というものが起動して開くようになります。これはplist専用のXML編集エディタで、非常に分かりやすくplistのXMLデータを編集できますので、カスタマイズをする人はぜひDevToolsをインストールしておきましょう。
★tcshのカスタマイズはtcsh.defaultsは使わないで！★
369ページにて、tcsh.defaultsの書き換えによるtcshのカスタマイズを行なっていますが、「tcshのカスタマイズはもっと簡単にできるのでは？」と思われる方もいるかと思います。その通りです（笑）。読んでいただければわかるように、これはあくまで「rootでないと修正できないシステム関連のファイルを修正する」一つの例としてあげたまでです。tcshのカスタマイズ法として紹介しているわけではありません。が、これを読んで「tcshは、こうやってカスタマイズするのが基本だ」と思われる方がいるといけないので、一応、補足しておきます。
tcsh（というよりcsh）は、ホームディレクトリに「.cshrc」というファイルを置くことで、そのユーザの利用環境をカスタマイズすることができます。これはtcsh.defaultsと同様、設定を記述したテキストファイルとしてこのファイルを保存すればよいのです。ですので、通常はtcshをカスタマイズする時は、この方法をとってください。
例えば、本書にてあげたように表示プロンプトを変更するのであれば、以下のようになります。
# csh (tcsh) rc file. if ($?prompt) then set prompt = "[%c7]%n>" #ここを本書にあるように適当に修正 endif
――このように記述してホームディレクトリに.cshrcファイルを保存すれば、tcshのプロンプトが変更されます。
★追加のコラム★ |
※本書は初版１刷のとき、レイアウトの関係で２ページの余白ページができてしまいました。何も書いてないページがあるというのは、数円分、損をした気分になるかも知れません。そこで、２刷より、余白だった２ページにコラムを追加してあります。
が、これでは１刷を購入された方に対し不公平となるので、編集側とも話し合った結果、追加コラムを以下に掲載することにしました。ごく簡単な内容のものですが、知っておくと多少は役に立つかも知れません。
（※133ページの余白コラム）
Cocoaアプリケーションが起動しない！
Mac OS Xのシステム関連のトラブルについてはPart 2のChapter 2にて触れていますが、「アプリケーションのトラブル」というのもMac
OS Xでは存在します。もっとも深刻なのは「Cocoaアプリケーションが、いきなり起動しなくなってしまう！」というものです。これは、実際に遭遇するとかなり焦りますから、ここで簡単に対処法を触れておきましょう。
Cocoaアプリケーションが起動しなくなる場合、その大半は「初期設定ファイルの破損」が原因です。Mac OS Xでは、アプリケーションの初期設定ファイルは、~/Library/Preferencesに作成されます（＝ユーザのホームディレクトリ内にある「Library」フォルダ内の「Preferences」フォルダ）。もし、Cocoaアプリケーションが起動しなくなったら、とりあえずこのフォルダを丸ごとデスクトップに移動して再起動してみましょう。そしてちゃんと起動したら、初期設定ファイルが原因です。
アップル純正のプログラムは、「com.apple.プログラム名.plist」というファイル名で初期設定ファイルが作成されます。フォルダの中を調べ、問題のアプリケーションの初期設定ファイルを探して削除し、それ以外のものを元に戻せば問題は解決します。
ただし、「Mail」についてはちょっとやっかいなので注意が必要です。（これについては225ページのコラムを参照下さい）
「スクリーンセーバ」システム環境設定が開けない！
システム環境設定で「スクリーンセーバ」を選ぶと強制終了してしまう、なんてトラブルも起こることがあります。これは、Custom Slide Showでフォルダを選んだ際に、そのデータが破損してしまった場合に起こります。
この問題は、スクリーンセーバの設定ファイルを削除すれば解決します。~/Library/Preferences/ByHost/というフォルダがあります。その中の「com.apple.screensaver.localhost.plist」「com.apple.SystemPreferences.localhost.plist」という２つのファイルが、スクリーンセーバの設定ファイルです。これらを削除し、システム環境設定を起動すれば、問題なくスクリーンセーバの設定が使えるようになります。
今のところ、スクリーンセーバ以外のシステム環境設定では、大きな問題は聞いていません。これらの設定ファイルも、やはり「Preferences」フォルダにあります。ですから、もし万が一、他のシステム環境設定でトラブルが起きた場合も、設定ファイルを探して削除すれば、おそらく解決するはずです。
また、こうしたトラブルは、OSのアップデートでかなり発生しなくなっています（コラム執筆時のバージョンは10.0.3）。Xをインストールしたら、最新のバージョンにアップデートしておくことをお勧めします。
（※225ページの余白コラム）
Mailが起動しなくなったら？
Mac OS付属のアプリケーションで一番の問題児は、「Mail」アプリケーションでしょう。こいつは実に様々なトラブルを引き起こしてくれます。361ページでは、もっとも身近な問題である「メールの文字化け」について説明してありますが、この他にも面倒を起こすことはあります。それらについてここで触れておきましょう。
まず、Mailが起動しなくなる問題。これは、３つの要因が考えられます。１つは、一般のCocoaアプリケーションと同様、初期設定ファイルの破損。２つ目は「MailBox」の破損。そして３つ目は「アドレスブックの破損」です。
MailBoxの破損というのは、文字通りメールを保存してあるMailBoxデータが壊れてしまったために起動できなくなるという現象です。MailBoxは、~/Library/Mail/というディレクトリに保存されています。これを開くと、「Mailboxes」とか「iTools/yamada@mail.mac.com」といったフォルダがあり、その中に「.mbox」という拡張子のファイル（？）が保存されているはずです。これが、受信したメールの内容を保存してあるMailBoxデータファイルなのです。
この.mboxファイルを一旦デスクトップなどに移動し、Mailを起動してみて下さい。もし起動すれば、MailBoxのどれかが破損しているはずです。
これでも起動できない場合は、アドレスブックの破損を疑ってみましょう。~/Library/Addresses/を開くと、そこに「Addresses.addressBook」といったフォルダが見つかるはずです。ここに、MailやAddressBookで登録したアドレスデータが保存されているのです。このファイルが壊れていても、Mailは起動できなくなります。やはりデスクトップに移動して起動するか確認してみて下さい。
届いたメールが消える！？
筆者が経験した、もっともとんでもないトラブルは、「届いたメールをなくしてしまう（！）」というものでした。確かにメールをダウンロードして受け取っているのに、どのMailBoxにも表示されず、消えてしまうのです。
これは、何らかの原因によりMailBoxのファイルへの書き込みが行えなくなってしまった場合に生じます。メールのデータは「Mail」フォルダ内に保存されますが、実をいえばここにある.mbox拡張子のファイルは、「パッケージ」と呼ばれる特別なフォルダなのです。このMailBoxファイルをControlキー＋クリックし「パッケージの内容を表示」を選ぶと、この中にあるファイル類を見ることができます。
通常、メールのテキストは、この中の「mbox」というファイルに保存されます。ところが、このファイルに書き込みできなかった場合には、Mailは臨時にスプーリングファイルを作成してそこに届いたメールを保存するのです。
もし、届いたメールが消失した場合には、どこかの「mbox」内にスプーリングファイルを作成しているはずですので、それを探してテキストエディタで開いてみましょう。届いたメールの内容が見つかるはずです。
★おまけの情報★ |
※本著作の内容とは特に関係なく、Mac OS Xについて「ちょっと知っておくといいかも？」と思った情報を、いくつかここにアップしておきます。まあ、拙著をお買い上げいただいた皆様への、「おまけ情報」と思って下さい。
★Mac OS Xがフリーズする？★
Mac OS Xはフリーズしない！と固く信じている人は多いようですが、稀に「マウスポインタ以外、何も動かない」状態に陥ることがあります。メニューをクリックしても反応がないし、どのウィンドウ、Dock、デスクトップをクリックしても全くそちらに切り替わらず、「フリーズした！」と思うことでしょう。
これは、実はフリーズではありません。カーネル部分で何か猛烈に時間のかかる処理をしているのです。特に、巨大なメモリを消費するような作業を行なった後など、メモリスワップのために数十秒から時には数分も、マウスポインタ以外何も動かない状況に陥ることがあります。これは、単に「猛烈に時間がかかっている」だけですので、待っていれば元に戻ります。慌ててマシンをリスタートなどせず、しばらく待ってあげて下さい。
今までの経験からすると、本当にフリーズすることは一度もありません。マジにやばい状態になった時には、「カーネルパニック」を起こすようです。ですから、反応が返ってこなくても、フリーズである可能性はほとんどないと考えてよいでしょう。
★ファイル・フォルダ名の「:」「/」記号には注意！★
ディスク／ファイル／フォルダの名前に「/」や「:」記号を使う場合には注意が必要です。Mac OS Xでは、これらの記号はFinderなどでの表示と内部的な表示が異なっているからです。
Macでは、「:」記号を使った名前はつけられません。そのことは御存じですよね？ 例えば「A:B」なんてファイル名を入力すると、自動的に：記号が−に変わり、「A-B」とされてしまいます。「/」記号はちゃんと使うことができます。
MacOSでは、ファイルのパスの区切りに「:」記号が使われています。アップルスクリプトなんかでファイルのパスを指定する時などは、「Macintosh HD:書類:Text」なんて具合に記述するわけです。こうやってディスクからそのファイルまでのフォルダ名を続けて記述することで、そのファイルの在り処を示すわけですね。
ところが、UNIXの世界では違います。「:」記号ではなく、「/」記号で区切るのです。本書でもターミナルをちょっと使っていますが、ファイルのパスは「/Users/Yamada/Documents/Text」なんて具合に、/記号で区切られていることがわかったはずです。そして「:」記号は使えるようになっているのです。
ここで、こういう疑問が当然湧いてくるはずです。「Finderで『/』を使った名前をつけたら、それは内部的にはどうなっているのか？」という疑問です。――Mac OS Xでは、Finderで「/」記号をつけた名前をつけると、それは内部では「:」に置き換えられるのです。例えば、Finderで「A/B」と名前をつけると、それはターミナルでls表示させた場合には「A:B」という名前で表示されます。Finderとターミナルで、名前が違うのです。
また、TextEditなどでオープンダイアログからファイル名を直接入力して開くような場合も同様です。「A/B」というファイルは、オープンダイアログでは「A:B」と入力しないと開けません。「A/B」だと「そこにあるAというフォルダ内にあるBというファイル」と認識されてしまうのです。
混乱をさけるため、個人的には「Mac OS Xでは、『/』『:』記号は名前に使わない」ということを推奨します。慣れない内は、なるべくよけいなことを考えず、シンプルに使えるようにしたほうがいいですからね。
※――なお、Mac OS Xでは、「Finderの表示は、ファイル名がそのまま表示されるわけではない」ということを肝に命じておきましょう。この「/」「:」記号問題もそうですし、本書の中でも触れましたが、「.app」拡張子はFinderでは一切表示されません。Finderは「OS内部で認識される名前を、ユーザに都合のいいような形になおして表示する」ものであり、実際の名前と必ずしも一致するものではないのです。
★Mac OS X版のSimpleTextは、標準でついている？★
Mac OS Xでは、TextEditというアプリケーションがついていて、これがSimpleTextの代りになっています。が、今でも多くのソフトなどのRead meは、従来のSimpleTextのファイルなので、うっかりダブルクリックしてClassic環境が起動してしまい、とっっってもうざったい、と思う人は多いんじゃないでしょうか。
実は、Mac OS X用のCarbon版SimpleTextというのが存在し、ちゃんとMac OS Xの中に入っているのです。といっても、標準では組み込まれません。これは、DevToolsをインストールしてないとダメです。――DevToolsを入れてある人は、/Developer/Examples/Carbon/SimpleText/Sources/を開いてみましょう。実はこれが、Carbon版SimpleTextのプロジェクトファイルなのです。
この中にある「SimpleText.pbxproj」というファイルをダブルクリックすると、Project Builderという開発ツールが起動します。「げっ」と思うでしょうが、何も心配はいりません。起動したら、現れたウィンドウ左上にあるトンカチのアイコンをクリックして下さい。これでプロジェクトのビルドを行ない、SimpleTextアプリケーションを作成します。
作業が終わったら、プロジェクトのディレクトリ内にある「build」の中を見て下さい。「SimpleText」のアプリケーションが作成されているはずです。これを、「Applications」フォルダに移動して使いましょう。ちゃんと、SimpleTextのファイルをダブルクリックすれば、このCarbon版SimpleTextが起動するようになりますよ。 …ただし、これは動作保証するものではないので、各自の責任において行なって下さい。
★tcshのコマンドを拡張しよう！★
tcsh（要するに「ターミナル」）は、コマンドラインによる操作ですから、なかなかMacユーザには馴染まないものです。が、逆にいえば「コマンドラインの世界に慣れる最良の教材」でもあります。ターミナルをいろいろ使い込むことで、内部がより見えてきます。
上に触れたように、ターミナルは、~/.cshrc（つまりホームディレクトリの.cshrcファイル）というファイルを用意することで機能をカスタマイズできます。といっても、「どんなことができるかわからない」ので使えないという人は多いでしょう。――そこで、とりあえず「面倒なコマンドを、簡単なコマンドとして登録しておく」ということをやっておきましょう。
これは「alias 《コマンド名》 《登録するコマンド》」という形で記述します。要するに、２つ目のコマンドを、１つ目のコマンドでも使えるようにしてくれるわけです。え？ 意味がわからない？ 例えば、こんな感じで使います。
alias private "cd /private/"
こうすると、「private」と打ち込むと、/private/ディレクトリに移動します。ディレクトリの移動は、いちいち長いパスをcdで打ち込んで移動するのは面倒ですから、こうやってよく使うディレクトリに移動するコマンドを簡単な単語として登録してしまうわけです。とりあえず「ディレクトリ移動の登録」あたりから始めて、いろいろカスタマイズしていくと、ターミナルもぐっと使いやすくなりますよ。
★AppleScriptのアプレットが文字化けする！★
Mac OS XのScript Editorで、Mac OS Xアプレットを作成すると、Display Dialogなどで日本語が文字化けするという現象が確認できています（ver. 10.0.3にて確認）。これは、Mac OS Xで国別情報の取得方法が変わったために、アプレットの国別情報が理解できず英語（デフォルト）と判断されてしまうために起こる現象です。
本書の362ページ「文字化けするCarbonアプリケーションをパッケージ化する」で、この種の国別情報が得られないために文字化けするアプリケーションをパッケージ化して文字化けを解消する方法を紹介しています。この方法を使って、アプレットの文字化けも解消することができます。
ただ、パッケージ化はちょっと面倒臭いですし、アプレットが大きくなってしまうのがイヤという人もいるでしょう。そこで、リソースを修正することで文字化けを解消する方法もここで紹介します。――ResEditやResorcererといったリソース編集ツールをもっている人は、こちらのほうが簡単でしょう。
まず、この後にアップロードしてある「修正用リソースファイル」をダウンロードして下さい。そして、作成したアプレットをリソース編集ツールで開きます。次に、修正用リソースファイルを開き、そこに入っている「plst」リソースのID=0番をコピー＆ペーストでアプレットに組み込んで下さい。これでファイルを保存してリソース編集ツールを終了すれば、アプレットは文字化けしなくなります。
これは、アプレットに限らず、他の文字化けするCarbonアプリケーションでも同様に使えます。もし、この種の文字化けがあったら試してみて下さい。
また、AppleScriptのアプレットにはもう１つ問題があります。実行後、最後に「スクリプトエラーが起きたのでスクリプトの変更を保存できませんでした」というエラーが表示されることがあります。これは、スクリプトに日本語の名前をつけた場合に起こります。アプレットは半角英数字でファイル名を指定するようにしてください。
※ただし、この修正によりいかなるトラブルが発生したとしても筆者は何の責任も負いません。自己の責任において行なって下さい。