管理者の理想と現実 3 概要 automount の導入 2 三膳孝通 定する。 インダイレクトマップ NFS の普及にともない、ディスクの共有もごく一ヨ難勺 におこなわれるようになった。しかし、ファイルサーバー のトラブルでクライアントが停止する、あるいは設定ファ イルを個別に用意する必要があるのでマシンごとに環境が 異なる、などの間題も生じてきた。これらの鮹夬ガ去の 1 っとして、 NFS 4.0 から automount カ甘是供された。 automount で提供される機能は便利そうで、以前の環 境から大幅な変更もせすに移行できるように思えた。とこ ろか現実はそう甘くなく、ある程度安定した運用が実際 にできるまでにはかなりの苦労をすることになったので ある。 そこで今回は、 automount を導入する際のトラブルと その対応去についてお話しする。 automount は、アクセスが生したときにファイルシス テムをマウントし、一定時間アクセスがなければマウント を外す機構である 1 。 automount を使用するワークステ ーションでは、管理するデーモンを起動するようにしてお ーは特別のものでなく、 NFS サーバーの機能 、、どのサーバーから何をど があれは・なんでもかまわない。 こへマウントする " といった管理情報は、マップファイル に入っている。 マップファイルには 3 不頁あり、それぞれ以下のよう な機能がある。 マスターマップ マウントボイントとそこて使用するマップファイルを指 1 1991 年 12 月号の「 UNIX Communication Notes 」でも紹介 104 されている。 マスターマップに指定したマウントボイントごとに用意 し、そのマウントボイントの下に置きたいディレクトリ を相封パスで指定する。すると、指定されたマウントボ イント以下のすべてのファイルが automount の管理 下に入る。 ダイレクトマップ 管理したいディレクトリを糸寸パスて指定する。特定の ディレクトリだけを管理したいときに使う。 automount では、複数のサーバーの利用やマッフファ イルの NIS による管理が可能である。これらによって、 より安全生、信頼性の高い、統一された環境の構築かでき るようになった。 導入、そして普及 automount の存在を知ったのは、かれこれ 2 ~ 3 年 前のことである。使用していた OS に標準で含まれてい て、すでに運用しているところから便利だという話も聞い ていた 当時の環境は、ホームディレクトリや /usr/local を NFS で共有していたがマシンの台数はさはど多くなく、 ディスクサーバーが頻繁に落ちて困ることもなかった。し たがって導入の必要性はそれほど強く感しなかったのだ が、新しい機能を利用してみたいという好奇心と、朋大の 設定をあまり変更せすに移行できそうだったことから、勝 手に何台かのマシンを設定してみた。これが導入の契機で ある。 UNIX MAGAZINE 1992.4

C コンパイラなら cc に決まっているのだから、わ ざわざ cc などというマクロを使わすに直接書いてもい いではないかという意見もあるかもしれません。しか し、本当にそうでしようか。 GNU C コンパイラを備 えたマシンもたくさんあります。これを使う場合は、 C コンパイラとして gcc を指定しなければなりません。 Makefile のなかに直接 cc と書いてあると、すべての cc を gcc に変更しなければなりませんが、マクロ cc を使っていれは、このマクロの値を gcc に変更するだ けでよいのです。 さて、この Makefile ではもう 1 つ新しいマクロ CFLAGS が登場しています。このマクロを定義している 行は見当たりませんし、既定義のものでもありません。 このように Makefile では、マクロが使用されているに もかかわらす値が設定されていなければ、デフォルトで 空文字列を値とするものとみなされるのです。したがっ て、前例でも CFLAGS というマクロは空文字列として 処理されます。この CFLAGS というマクロは、コンパ イル時のオプションカ甘旨定できるようになっているの です。 では、 Makefile のなかでコンパイル時にかならす CFLAGS の値を参照するようにしておくと、いったい どこが便利なのでしようか。デバッガを使うために一 g オプションを付けたり、デバッグの終了後一 0 オプショ ンを付けて再コンパイルする場合、 Makefile のコンパ イルに関するすべての部分を編集せすに ( マクロ定義の 変更だけで ) 目的の動作が実現できるのです。 CFLAGS は既定義のマクロではありませんが、 make コマンドにちょっと変わった方法で扱われます。ただ こで述べた目的以外にはできるかぎり使わない し、 ほうが賢明です。この、、ちょっと変わった方法 " につい ては、次回にお話しする予定です。 特別な意味をもつマクロ 既定義のマクロはそれだけで意味をもっていました が、それよりもっと重要なものもあります。そのよう なマクロに、 SHELL 、 VPATH 、 MAKE などがあります。 基本的には既定義のマクロと考えてもかまいませんが、 これらのマクロが使われた場合には、 make コマンドの 実行方法がすこし変更されます。 112 ます SHELL ですが、このマクロが設定されている場 合、インストラクションとして指定されたコマンド群は この SHELL マクロの値であるコマンド・インタープリ タによって解釈、実行されます。 しかし実際には、このマクロの値を変えることはあ まりないでしよう。デフォルトでは / b 土Ⅱ / sh が使われ ます。マシンによって同し Makefile か動作しない場合 には、この SHELL マクロの値が /bin/sh 以外のもの になっていることもよくあります。そのようなときは、 SHELL マクロの値を /bin/sh に設定すれば正しく動作 させることができます。 次は VPATH です。これは、 make コマンドが必要な ファイルを捜すための検索パスの指定に使われます。複 数のディレクトリを指定する場合は、各ディレクトリを で区切って列挙します。 make は、ターゲットや依 存すると指定されたファイルの最終更新時刻を取得す るために、ファイルシステムに対して要求を出します。 このとき、通常は指定されたファイルがカレントディ レクトリに存在するか否かを調べます。カレントディ レクトリに存在しない場合、 VPATH マクロが設定され ていればこのマクロに設定されたディレクトリを順番 に検索します。このマクロは、バージョン管理などに 使うと便利ですが、これについては稿を改めてお話し します。 もう 1 っ特別な意味をもっマクロとして、 MAKE があ ります。このマクロの説明に入る則に、 make コマンド の 1 つの機能についてお話ししておきましよう。 make コマンドには、ほかの UNIX 上のコマンドと同様にコ マンド行引数やオプションを与えることができます。そ れらのオプションのうち、 -n を指定するとインストラ クションを実行せすに、ふつうに make コマンドが実 行されたらどのようなインストラクションを実行する のかを画面に表示します。 では、 make コマンドを実行したとき、 MakefiIe の なかで make コマンドの実行が指定されていると、後 者の make はどうなるでしようか。 通常の実行では、なんの問題もなく make コマンド を呼び出すことができます。しかし、一Ⅱオプションを 付けると、なかから呼び出される make は自身か呼び 出されることを表示するだけで、何をするかは表示しま UNIX MAGAZINE 1992.4

連載 gcc を使用する場合、 YES に設定する。 続ウインドウ・システムについて一② 表 4 有用なパラメーター覧 パラメータ名 HasGcc Standard Defines DefauItCDebugFlags ServerDefines ServerCDebugFlags LibraryDefines LibraryCDebugFlags BinDir UsrLibDir LibDir ManDirectoryRoot Proj ect Root BuiIdXInputExt BuiIdXInputLib InstallFSConfig InstallXdmConfig InstaIIXinit Config lnst aIILibManPages Xd mServerType HasXdmAuth PexShmIP C LibManSuffix ManSuffix BuildXsi BuildXimp BuildFontServer BuildFonts BuildPex BuildPexClients BuildPexExt BuildServer 説 明 コンパイル時につねにイ寸加すべき -D オプションを設定する。 テンヾック時には、このパラメータにテンヾッグ用のオプションを設定する。 サーノヾーのコンパイル時にイ勒日すべき一 D オプションを設定する。 サーバーのデバッ夘には、このパラメータにテンヾッグ用のオプションを言殳定する。 ライプラリのコンパイル時に付加すべき -D オプションを設定する。 ライプラリのテンヾック芋には、このパラメータにデバッグ用のオプションを成疋す る。 バイナリがインストールされるディレクトリを設定する。 ライプラリがインストールされるディレクトリを設定する。 X 用のデータファイルがインストールされるディレクトリを設定する。 マニュアルページがインストールされるディレクトリを設定する。 X の実行環境を 1 カ所にまとめておくために使用する。 ProjectRoot が設定さ れている場合、 BinDir 、 UsrLibDir 、 LibDir 、 ManDirecotryRoot はそれぞ れ ProjectRoot/bin 、 ProjectRoot/1ib 、 ProjectRoot/1ib/X11 、 Projec- tRoot/man に設定する。 Xlib に含める国寸応の実装として Xsi を尺する場合、 YES に設定する。 Xlib に含める国び寸応の実装として Ximp を尺する場合、 YES に設定する。 フォントサーノヾーをコンパイルする場合、 YES に設定する。 フォントを作成する場合、 YES に設定する。 X11R5 のフォントフォーマット pcf は、どのサンフ。ルサーバーでも読み込めるので、フォントは高速な討算機のみで生成 することもできる。 PEX をコンパイルする場合、 YES に設定する ( デフォルトは YES ) 。 PEX のクライアント群をコンパイルする場合、 YES に設定する。 PEX のサーバーイ則をコンパイルする場合、 YES に設定する。 サーバーをコンパイルする場合、 YES に設定する。通常、 machine. cf のなかで xinit の設定ファイルをインストールする場合、 YES に設定する。 xdm の設定ファイルをインストールする場合、 YES に設定する。 フォントサーバーの設定ファイルをインストールする場合、 YES に設定する。 入力工クステンションのライプラリをコンパイルする場合、 YES に言殳定する。 入力工クステンションのサーバー側をコンバイルする場合、 YES に言殳定する。 YES に、サポートされていないものでは NO に設定する。 あらかしめ定義されており、サーバーがサポートされているプラットフォームでは PEX のクライアントとモニターとの通信に共有メモリを使用するかどうかを指定す 能は米丿外では使用できない。 DES を使った認証プロトコルを使用する場合、 YES に設定する。ただし、この機 を、もたない場合は "fs" を指定する。 xdm の設定ファイルの内容を指定する。ローカル・ディスプレイをもっ場合は、 ws" ライプラリのマニュアルページをインストールする場合、 YES に設定する。 コマンドのマニュアルページのサフィックスを言殳定する。 ライプラリのマニュアルページのサフィックスを設定する。 る。デフォルトはプラットフォームにより異なる。 NO YES NO NO NO YES WS NO 3 デフォルト値 /usr/bin/X11 /usr/lib /usr/1ib/X11 /usr/man BuiIdPex の ( 直 BuildPex の ( 直 り、あらかしめいくつかの構築手順が用意されている。い すれも、 make に 1 つだけ引数を指定する形式になって いる。 ・ make Wor1d 完全にゼロからツリーを明冓築する。 UNIX MAGAZINE 1992.4 以則コンノヾイノレし た結果のオプジェクトや、生成された MakefiIe なども すべて消去される。内部的には、次のコマンドを連続的 に入力した場合と同しである。 make clean make Makefi1e 59

で設定することもあるでしよう。 make コマンドでは、 これらの環境変数を MakefiIe のなかでマクロとして利 用できます。 通常、それぞれのユーサーのホームディレクトリの 位置は、 HOME という環境変数に値が入っています。 の値を使って、別のディレクトリの位置を指定するこ ともできます。たとえは、 LIBDIR = $(HOME)/1ib と定義しておくと、 LIBDIR というマクロには、そのユ ーサーのホームディレクトリにある lib というディレク トリが設定されます。 ここまでの説明では触れていない機能 この例では、 を 1 つ利用しています。それは、はかのマクロの値を 使って別のマクロを設定するという機能です。上の例 の場合、 LIBDIR というマクロを設定するために HO というマクロの値を使っています。このように はか のマクロの値を使ってマクロを設定することも自由に できます。しかし、制限が 1 つだけ設けられています。 それは、、、相互に参照する形式でマクロを設定してはな らない " というものです。たとえば、次のようなマクロ 指定は許されません。 A = a $B B = b $A これは、 A の値を決めるためには B の値が、その B の値を決めるためには A の値が必要になってしまうの で、どちらの値も決定できないからです。 マクロの展開 これで、マクロの値を設定し、その値を使うことはで きるようになりました。しかし、 make にはマクロの利 用に関するもっと便利な機能もあります 1 。 さきはどの例では、オプジェクト・ファイルを 1 つ の OBJS というマクロに設定していました。 こではオ プジェクト・ファイルしか使っていませんが、すべて のソースファイルをプリントアウトしたい場合などは、 ソースファイルもマクロにしておくと便利でしよう。た とえば、ソースファイルが . c で、対応するオプジェク こで説明する機能は SystemV 系のマシンと Sun では使えます が、 BSD 系のマシンで利用できるものは少ないようです。 1 UNIX MAGAZINE 1992.4 IJN Ⅸ流プログラミング 18 ト・ファイルが . 。で終っているというように、相違点 がサフィックスだけの場合、多数のファイルについて同 様の記述をしなければならないのは面倒です。このよう なとき、サフィックスの部分だけを変換するマクロの参 照方法があるのです。たとえば、 SRCS = maln . c sub . c $(SRCS : . c =. 0 ) OBJS と指定すると、 SRCS のそれぞれの要素の . c という部分 が . 。に変換さ OBJS に設定されます。つまり、この 定義では OBJS として main. 0 sub. 0 という値を指定 したことになるのです。試しに . c という部分をもたな いもの (defs. h など ) を SRCS に設定すると、この値は そのまま OBJS に渡されます。つまり、もとになるマク ロの等号の前にマッチした部分が等号の後ろに書かて いるものに置き換えられ、マッチしないものはそのま まの値になるのです。 既定義のマクロ こまでユーサーが定義するマクロについてお話し してきましたが、じつはシステムによってすでに定義 されているマクロも存在します。よく使われるものに は、 cc や pc などがあります ( それぞれ C コンパイラ と pascal コンパイラを示します ) 。これらを利用して MakefiIe を記述すると、さきほどの例は次のようにな ります。 % cat Makefi1e SRCS = maln . c sub . c $(SRCS: . c =. 0 ) OBJS HDRS = defs . malll . 0 sub . 0 : $(OBJS) $(CC) $(CFLAGS) ー。 main $(OBJS) : main. c $ (HDRS) $(CC) $(CFLAGS) -c main. c sub . c $(HDRS) $(CC) $(CFLAGS) -c sub . c こで使っている cc が既定義のマクロです。通常、 このマクロの値は cc で、これを指定しておけば C コ ンパイラが使えます。この値は、デフォルトのものだと 思ってください。ューザーが自由に書き換えることもで きます。 111

連載 An lntroduction to X Window System ー@ mappedWhenManaged リソースを、、 0ff 〃に設定する と、部品をウインドウから消すこともできます ( 図 8 ) 。 ただし、これはウインドウ部品の生成自体をやめるので はなく、人間の目に見えないように、、アンマップ〃という 操作をしているだけです。アイコン化するときのウインド ウの状態を思い浮かべれば、分かりやすいかもしれません。 多くのクライアントでは、利用者によるリソースの変更は 考慮されていません。したがって、アイコン化された状態 からウインドウを再表示させる、、マップクという操作が発 生すると、隠しておいたはすのものが現れてしまうなどの 不都合が生しることもあります。 部品自体の形の変更は、リソース設定の基本です。多く の部品で、大きさや太さが変えられます。 Command 部品 などは、 Shape 拡張を利用して楕円形に変更するような機 能も備えています。 ・大きさを変える (Geometry 、 Width 、 Height リソー ス ) 通常、アプリケーション・ウインドウ全体の大きさを変 えるには、アプリケーションと同名の SheII 部品の Geom - etry リソースを変更します。指定方法は、アプリケーショ ン起動時の一 geome y オフションと同様で、 く X 幅〉 x く Y 幅〉士く X 座標〉士く Y 座標 > と設定します。 個々の構成部品を変史する場合、横幅は Width 、縦幅は Height リソースにピクセル幅に相当する数値を指定しま す ( 図 9 ) 。ただし、アプリケーション全体がリサイズされ るときは、これ以外の大きさを指定しなければなりません。 たとえは・、 Composite に属する部品によって配置カ鴃ま 形の変更 図 9 大きさを変える (Geometry 、 Width 、 Height) 3 十 118 XCa1c . ti . Corrmand . width: XCa1c . ti . Corrmand. height: XCa1c . し i . bu しし 0n34 . height : XCa1c . ti . buしし0n35. height: 32 15 3 4 3 4 る子ウインドウに相当する部品がこれにあたります。 このような場合、構成部品の大きさは自身の大きさを指 定するリソースだけでなく、 Constraint リソースの値に も大きく影響されます。 Constraint リソースでは、子ウィ ンドウの位置や大きさに関係の深い、子ウインドウ相互の 間隔、配置、占める割合を設定する情報を記述します。 Constraint リソースは設定対象の部品そのものではなく、 その親ウインドウにあたる Composite に属する部品が規 定する位置や大きさに関するリソースです。しかし、個々 の構成部品を拘束する (Constraint) リソースとして構成 部品側のリソースになっています。ですから、 Constraint リソースは親ウインドウに相当する Composite に属する 部品の解説を参照し、実際の設定はその子ウインドウに相 当する構成部品側でおこないます。 さて、話をもとに戻しましよう。大きさの変更に関係す る Constraint リソースでは、 Edge クラスのリソース (top 、 bottom 、 left 、 right) を、、鎖ク (chainTop 、 chainBottom 、 chainLeft 、 chainRight など ) でつないだ り、 rubber として比率を保ってゴム紐でつなぐ場合、前述 の Width と Height に加えてこの鎖の長さの影響を受け ます。鎖の長さとは、 vertDistance あるいは horizDis- tance の Thickness クラスのリソースで規定される幅の ことです。つまり、これらはその部品の大きさだけではな く位置にも関係しているのです。 なお、鎖を結ぶことと鎖の長さは、どちらも fromVert と fromHoriz ( どこに結びつけるか ) の Widget クラスの リソースの設定に影響を受けます。このリソースを設定し なければ、親ウインドウに対する位置と大きさが決められ ますが、同し子レベルにあたる部品の名前を設定すると、 相対的な位置間隔が規定されます。これらの設定によって、 全体がリサイズされたときの大きさや位置を規定します。 ・線の太さを変える (BorderWidth リソース ) 、、線の太さ〃でお馴染みなのは、部品の外周に沿って引か れる枠でしよう。これは個々の構成部品の輪郭になります から、部品自体の姿を表示する必要があるときは、 Border- Width リソースにピクセル幅を指定します。また、マウス カーソルが対象部品の上にあることを太めの枠で示したい 場合には、 HighlightThickness リソースにピクセル幅を 指定します ( 図 10 ) 。 項目を分ける線は、これらとは独立したリソース項目に UNIX MAGAZINE 1992.4

連載 書のように、、引く " ものではなく、通して、、読む " もので 続ウインドウ・システムについて一② 3 はかにそう考えている人がいるかどうかは知らないが、筆者ク寺論であ には、条件によって実行する命令列を切り替えたり、設 make コマンドを使用しておこなわれる。 make コマンド さきに触れたように、 X の構築作業は基本的にすべて X 構築システムの構造 は、 X 構築システムの構造を説明する。 構築システムを眺めながら知識を増やすしかない。次節で の知識を要求されることもある。これについては、実際に かなりの知調ア得られるが、場合によっては、さらに細部 この 2 つを読破するだけでも X 構築システムに関する paper. PS. Z である。 式のファイルは mit/hardcopy/config/usenixws/ doc/config/usenixws/paper. ms 、 PostScript 形 してはいけない。 ro 仕のソース形式のファイルは mit/ の実情に沿っていない部分もあるので、内容を鵜呑みに とよい。ただしこのドキュメントは若千古く、 XI 1R5 る。構築イの経験がなければ、ます最初に読んでみる X 構築システムをごく簡単に解説したドキュメントであ dow System ・ Configuration Management in the X Win- イルは RELNOTES. PS である。 のファイノレは RELNOTES. ms 、 PostScript 廾彡式のファ うファイル名で置かれている。なお、 r 。仕のソース形式 ーの mit ディレクトリの直下に、 RELNOTES . TXT とい OS の設定や制限事項などか書かれている。ソースツリ 際の構築作業の進め方、設定すべきパラメータの解説、 る。それも斜め読みではなく、熟読したほうがよい。実 リースノートとする ) だけは寸に読んでおくべきであ 構築作業をおこなう際、このドキュメント ( 以下、リ Release Not es ・ X Window System, Version 11 , Release 5 低限次の 2 つは読んでおく必要がある。 ないが、 X11R5 に付属しているドキュメントのうち、最 X 構築システムを知るために読むべきものはそう多くは あると考えられる 3 が、 x のドキュメントも同様である。 56 る。 定パラメータをほかのファイルから取り込む機能がない 4 。 したがって、 make が実行される前にすべてのディレク トリの Makefile を修正し、正しいパラメータを主して おかねばならない。これには、 imake というツールが使 用されている。 imake は UNIX 標準のツールではなく、 X のリリーステープに含まれているフリーソフトウェアで ある。 imake は、機種依存の設定ファイルとサイトごとの設定 ファイルを読み込み、続いてターゲットをコンパイルする ためのルールを言己したファイル lmakefile をカレン トディレクトリから読み込み、最終的にカレントディレク トリに適切な MakefiIe を生成する。機種依存の設定ファ イルやサイトごとの設定ファイルは mit/config の下に まとめられており、すべてのディレクトリで MakefiIe を 生成する際に読み込まれる ( 以ード、 mit/config にあるこ れらの設定ファイルを構成ファイル " と呼ぶ ) 。この欟冓 により、機種依存の設定やサイトごとの設定 ( 以下、これ らの設定パラメータを構成パラメータ " と呼ぶ ) を 1 カ 所にまとめることができ、ツリー本に景グする構成パラ メータ刎正をすべての MakefiIe に正確に反映できる。 また、 imake はファイルを読み込むときに cpp を通す ようになっている。このため、構成ファイルや lmakefile は、 cpp の提供する柔軟なマクロ機能を使って記述でき る。燧冬的に MakefiIe に書き込まれるコンパイルのため の命令列 ( ルール ) などは、ターゲットによって異なるこ とはほとんどない。このため、オ剽勺なルールに展開され るマクロか構成ファイルに定義されており、各ディレクト リの lmakefile はそれらのマクロを使ってごく簡潔に記述 できる。 全体を間違いなく構築するためには、 Makefile に構 成パラメータが正しく反映されていることも必要である が、ソースファイル間の依存関係カ随切に央されている ことも重要である。 X 構築システムでは、 makedepend というツールを使用してこの問題の解決を図っている。 makedepend は、引数に指定されたファイルを C 言語 のソースファイルであると仮定し、 #include によって読 み込まれるファイルを再 ) 髄勺に検査することにより、ヘッ ダファイルの依存関係を Makefile に追加するツールであ 4 、 include " 命令を備えている make もあるが、この機能が使えないシ ステムもあるので、 X 構築システムでは使用されていない。 UNIX MAGAZINE 1992.4

連載 An lntroduction t0 X Window System 図 5 フォントを変える (Font) XCa1c . ti . bevel . LCD . font: . screen 1234567890 D EG —adobe-helvetica-bold ー☆ー 18 ー☆ー☆ー☆ー☆ー☆ー iS08859 ー 1 ー r - ☆ 1234 % 788 —misc—marumoj i— XCa1c . ti . bevel . LCD . font : . screen 注 : 指定している marumoji フォントは、 PDS として配布されたものです。 ☆ ☆ー☆ー☆ ー 14 ー ☆ー☆ - ☆ー☆ー☆ ー i s 08 8 59 -1 DEG 図 6 項目の左右にビットマップをイ寸ける (leftBitma rightBitmap) XCalc . ti . bu しし 0n7 .1eftBitmap: /usr/local/bitmaps/sin. xbm XCalc . ti . bu しし 0n8 .1eftBitmap: /usr/local/bitmaps/cos . xbm XCa1c . ti . buしし0n9 .1eftBitmap: /usr/local/bitmaps/tan. xbm 注 : sin. xbm などのビットマップ・ファイルは、あらかしめ bitmap コマンドで作っておきます。 図 7 項目表示をビットマップに (Bitmap) XCa1c . し土 . bu しし 0n3 . bitmap: /usr/local/bitmaps/sqrt . xbm うが効果的でしよう。 フォント名は XLFD と呼ばれる論理的な長い名称なの で、設定にはかなり苦労します。しかし、 xfontsel コマン ドを利用すれば気に入ったフォントが簡単に指定できます。 なお、設定の際にフォント名のすべての要素を記述してし まうと、異なるサーバー環境では利用できないこともあり ます。ですから、自分が最低限必要とする項目だけを指定 し、そのほかは、、 * 〃を使って緩やかに指定したほうがよ いと思います ( 図 5 ) 。 xcalc . に土 . Command. mappedWhenManaged : Off ・項目の左右にビットマップを付ける (leftBitmap また メニューが使われています。このメニューのモード選択の は rightBitmap リソース ) 項目では、選択されているときには項目表示の右側に、、レ〃 ( チェック記号 ) が付けられています。このように、アプリ SmeBSB ( シンプルメニューの項目 ) 、 Label( ラベル表 ケーションカ頓目の左右にビットマップを付ける機能を利 示 ) 、 Command( コマンドボタン ) 、 MenuButton( メニュ 用している場合、ユーサーがこのピットマッフ。付加機能を ーボタン ) 、 Repeater( リピータボタン ) 、 Toggle ( トグル 使うのは避けたほうがよいでしよう。 ボタン ) 部品では、文字による項目表示の左側にピットマ ップ・イメージを表示させることができます。そのために ・項目表示をビットマップに ( Bitmap リソース ) は、 leftBitmap リソースにビットマップ・ファイル名を指 定します ( 図 6 ) 。 SmeBSB 、 Label 、 Command 、 MenuButton 、 Repeater 、 Toggle の各部品では、文字による項目表示を このとき指定されるピットマップ・ファイルは bitmap ピットマップ・イメージに変えることもできます。それに コマンドによって作られる形式で、システムとして提供さ れるものは・・・ /include/X11/bitmaps ディレクトリに収 は、 Bitmap リソース設定にピットマップ・ファイル名を められています ( ・・・は / usr 、 / usr / X11R5 など ) 。 指定します ( 図 7 ) 。 シンプルメニューで構成される項目表示部品 ( SmeB - editres を使ってあるクライアントに 1 度設定した場合、 もとの文字表示に戻すにはクライアントの再実行以外に SB ) では、文字による項目表示、左側のピットマップ・イ 方法はありません。たとえ設定内容を空白にしても、リソ メージに加え、 rightBitmap リソースを利用すれば右側に ースの項目を 1 度設定すると、、空′′に戻せないからです。 もピットマップ・イメージが表示できます。 xterm などで、コントロールキーとマウスの中央ボタン ・部品を消す (mappedWhenManaged リソース ) を押したときに現れるメニューには、部品としてシンプル 図 8 部品を消す 囹 calculator (mappedWhenManaged) 0 DEG 117 UNIX MAGAZINE 1992.4

連載 An lntroduction tO X Window System 図マウスカーソルを変える (Cursor) マウスカーソルを移動すると、 ロロロ と設定しておき、対象部口上に XCa1c . し土 . but し 0n37. cursor: heart XCa1c . ti . bu しし 0n3 6 . cursor : exchange 0 凵 IYI E . 0 0 凵ーⅥ EXC izontal リソースに Never ( 表示しない ) 、 WhenNeeded ( 必要時のみ ) 、 AIways ( つねに表示 ) を設定すれば変更で きます ( 図 13 ) 。 ・マウスカーソルを変える ( Cursor リソース ) マウスカーソルの形状は、部品ごとに設定できます。変 更する場合は、 Cursor リソースにカーソル名 ( 1991 年 10 月号の図 1 参照 ) を設定します。たとえば、 shuttle を設定 すればスペースシャトル型のカーソルに、 trek を設定する とスタートレック型のカーソルになります ( 図 14 ) 。 1 つの部品でも、マウス動作ごとにマウスカーソルを変 化させて操作の意味を分かりやすくューザーに伝えるもの もあります。たとえば Paned の場合、グリップを擱む乍 に合わせてマウスカーソルの形状が設定できます。 グリッフ上にマウスが位置する場合のカーソルの形状 を指定する gripCursor ( 水平専用の horizontalGrip- Cursor 、垂直専用の verticaIGripCursor) 、移動させる方 向に合わせた upperCursor 、 lowerCursor 、 leftCursor 、 rightCursor が、任意移動のための betweenCursor ( 水平 専用の horizontalBetweenCursor 、垂直専用の ver- ticalBetweenCursor) が設定できます。 同様にスクロールバー上の移動動作についても、スクロ ールバー上にマウスが位置する場合のカーソル形状を指 定する scrollVCursol ( 垂直専用 ) 、 scrollHCursol ( 水平 専用 ) 、移動方向に合わせた scroIIUCursoI ( 上 ) 、 scroIID- Cursol ( - ド ) 、 scrollLCursol 佐 ) 、 scrollRCursol 佑 ) が 設定できます。 ・アイコンを変える (IconPixmap と IconMask リソー ス ) アプリケーションをアイコン化したときのアイコン表 示を変えるには、アプリケーションの名称と同し名前の 120 Shell 部品の IconPixmap リソースと、その輪郭を示す IconMask リソースにビットマップ・ファイル名を設定し ます。 ただし、アイコン表示に関してはウインドウ・マネージ ャーがこれらの設定に優先して働くことがあります。その 場合、アイコンの名前には IconName 、ウインドウ・マネ ージャーのウインドウのタイトル表示には TitIe という リソースが使われます。これらのリソースには、両方とも 文字列を設定します。 ーロに配置の変更といっても、部品そのものの配置を変 えることもあれば、部品内部で調整することもあります。 まず、部品そのものの位置、間隔の変更について説明し、 そのあとで代表的な部品内部の調整項目について説明しま しよう。 ・位置と間隔を変える ( X 、 Y リソース ) アプリケーション・ウインドウ全体の位置を変えるに は、大きさを変える場合と同しリソース - ー SheII 部品な どの Geometry リソースを変更します。 部品の配置は、基本的には X 、 Y リソースにそれぞれ X 軸方向、 Y 軸方向の座標を設定して変更します。この 標〃は部品の親ウインドウの左上角が原点となり、右方向 に X 座標が、下方向に Y 座標がピクセル単位で増加して いきます。 しかし、このような変更調節ができるのは、構成部品が 個々に独立して配置されている場合です。複数の部品が配 置されるときは、 Form 部品のような Composite に属す る部品によって本を調整するほうが一般的です。そのよ うな場合、部品の表示位置については、「大きさを変える」 のところでもお話ししたように、 Constraint リソースが 影響します。注意してください。 Composite に属する部品によって配置を決めた場合、 top 、 bottom 、 left 、 right の Edge クラスのリソース ( 設 定される値は、 chainTop 、 chainBottom 、 chainLeft 、 chainRight 、 rubber) 、 vertDistance と horizDistance の Thickness クラスのリソース ( 設定される値は間隔 ) 、 fromVert と fromHoriz の Widget クラスのリソース ( 設定される値は基準とする部品名 ) が変更対象となりま 配置の変更 UNIX MAGAZINE 1992.4

続ウインドウ・システムについて一② 複数のプラットフォームに対して構築するとか、ある 去する。 連載 % cd /usr/src/X11R5 % find mit —name \ * . 0 て Ig —print \ いはソースツリーをきれいな状態で保存しておきたい場合 は、、シンポリックリンク・ツリー " を作成し、そちらで 作業できる。これに関してはリリースノートの 3.2 節に説 明されている。 シンポリックリンク・ツリーは一見かなり有効にみえる が、ディスク領域的には割高である。ソースコード全体の シンポリックリンク・ツリーを作成すると、それだけで約 20MB を消費する。ディスク領域の計算から落としてし まいがちだが、この容量もあらかじめ確保しておく必要が ある。また、シンポリックリンクは実体がないのにノード だけは使うので、 i ノード領域が足りなくなる可能性もあ る。デフォルトの状態でファイルシステムを作成している 場合はこういうことはまずないが、心配ならば df ー土で 確認してみるとよい。もし i ノード領域か不足している場 ロ、シンポリックリンク・ツリーをあきらめたとしても、 オプジェクト・ファイルが作成できなくなる可能性がある ので、ファイルシステムを作りなおしたはうがよい。 構成パラメータの設定 UNIX MAGAZINE 1992.4 ため、バイナリやデータはかならす決められた場所にイ かにデータファイルの所在がハードコードされる。この を制御するパラメータである。 X では、バイナリのな 表 4 に記したように、実行形式をインストールする場所 ・ ProjectRoot 者のサイトでの site. def ファイルの内容を示す。 た構成パラメータについて説明する。なお、リスト 1 に筆 設定できる。以下、実際に筆者のサイトで検討し、設定し 基本的には、すべての構成パラメータは site . def で あとの運用も考慮したパラメータの設定が重要である。 などのファイルも参照する必要がある。構築だけでなく、 を決める。場合によっては、ソースツリーにある README リリースノートの 3.3 節を参考にして、必要なパラメータ 次に、構築に必喫な構成パラメータを設定する。表 4 や ンストールしなけれはならない。したがって、 Project- Root の設定、あるいは BinDir 、 LibDir 、 UsrLibDir などの設定は最初に熟考すべきである。 ProjectRoot を設定すると、指定したディレクトリ の下に実行環境か構築される。ファイルの置き場所は XI 1R4 のときと異なってしまうが、そのディレクト リ (/usr/X11R5 など ) を NFS マウントするだけ で、ほかの計算機と実行環境が共有できる。筆者のサ イトでは、複数の計算機 (SPARCstation シリーズ ) で実行環境を共有することを考え、 ProjectRoot を /usr/X11R5 に設疋することとした。 ・ BuiIdXsi 、 BuiIdXimp 前回説明したように、 X11R5 では国際イびお能をサ ポートする際に、 XIib と一体化する方式を採用してい る。そして、国際化対応能のサンフ。ル実装には Xsi と Ximp の 2 つの〕尺肢がある。 選択前に、両者の入力サーバーや変換サ→ヾーに関する ドキュメントを読む必要がある。 contrib/im/Xsi と contrib/im/Ximp にソースコードがあり、それぞれ に README やマニュアルページが用意されている。ど ちらがよいかいちがいにはいえないが、 Xsi は日ごろ慣 れ親しんでいる Wnn をサホートしていること、 Ximp は JLE か載っていないとコンパイルできない部分があ ることから、 Xsi を選択することとした。 ・ StandardDefines リリースノートの 3.4.1 節および contrib/im/Xsi/ README. sun には、 Xsi を選択した場合、 -DX-WCHAR -D-XLOCALE という定義を StandardDefines に追加 しなけれはならないと記述されている。あとで分かっ たことだが、同時に一 DX 乢も加えておかないと CON- TRIB にある Xsi 対応のツールをコンパイルする際に 不都合が生しる 10 ・ ManSumx ProjectRoot を / Ⅱ s て / X11R5 に設定しているので、 マニュアルページのインストール・ディレクトリは /usr/XIIR5/man に成疋される。システムのマニュア ルページ (/usr/man にある ) とまざることはないので、 10 これはどこにもされていない。 サフィックスは、、 1 " カましいと考えられる。 63

マクロ名 = マクロの値 という形式で指定します。たとえば、オプジェクト・フ ァイルの並びをマクロとして指定するためには、 Make- OBJS = main. 0 sub. 0 file に次のような行をしておきます。 110 となります。 JUGEMUJUGEMU 凵 GOKOUNOSURIKIRE というマクロの値は、 凵 GOKOUNOSURIKIRE LONGF I LENAME=JUGEMUJUGEMU\ たとえば、 文字に変換されます。 この場合、 2 行目の先頭にある空白文字列は 1 つの空白 ければ複数行をそのマクロの値にすることもできます。 行で書ききれないときは、行末に逆スラッシュ ( \ ) を付 が含まれていても、そのまま値として認識されます。 1 から行末までカイ直とみなされます。この部分に空白文字 次は、マクロの値です。マクロでは、等号 ( = ) の直後 うようにしてください。 ありませんが ) 、はじめてほかの文字をマクロとして使 クロ名に使う文字列が足りなくなったときに ( めったに てマクロ名を定義しても十分に用は足りるはずです。マ れる記号も存在するためです。通常は、この規則に従っ ほかに数字と下線だけと断わったのは、別な解釈をさ なります。また、先頭の文字に続けるものは大文字の 字にしておけは・ファイル名とマクロ名が区別しやすく イル名は小文字で表現されますから、マクロ名を大文 も行頭に書かれるので紛らわしいのです。一般にファ イル名 ( ターゲット ) カ己述されます。一方、マクロ名 Makefile では、依存関係を指定するために行頭にファ ます、大文字を使う理由を説明しておきましよう。 使って表せば、 [A-Z] [ A ー zo ー 9 」 * となります。 ( ー ) のいすれかを使うようにしてください。正規表現を 文字の英字て始め、大文字の英字、数字、あるいは下線 マクロ名には英数字や記号の一部が使えますが、大 は main ・。と sub. 。を指定しています。 ではマクロ名として OBJS を指定し、マクロの値として なお、マクロ名は行頭に書くようにしてください。 マクロ定義の例を挙げる前に、マクロの値の利用方 法をみておきましよう ( 値を設定するだけでは、なんの 役にも立ちませんから・・・・・・ ) 。マクロの値を使うには、 マクロ名を括弧 ( ( ) ) や中括弧 ( { } ) で括り、その前 にドル記号 ( $ ) を付けます。これにはちょっと楽をする 方法があり、マクロ名が 1 文字の場合にかぎり、括弧 で括らなくてもよいことになっています。 ここまでのところは、理解できたでしようか。では、 マクロ定義とマクロの使用例を見てみましよう。題材 としてとりあげる Makefile は、前回の最後の例をマク 口を使うように編集しなおしたものです。 % cat 1 2 3 4 5 6 7 8 9 10 11 12 ーⅡ Makefi1e OBJS = main. 0 \ sub . 0 HDRS = defs . 五 maln . 0 sub . 0 : $(OBJS) cc ー 0 main $(OBJS) main. c $ (HDRS) CC —C main. C sub. c $(HDRS) CC —C sub . C この例では、 OBJS というマクロには mai Ⅱ . 0 sub. 0 という値が設定され、 HDRS というマクロには defs という値が設定されています。 OBJS というマクロの指 定方法がさきほどの例とはすこし異なりますが、これは \ を利用して複数行カ甘旨定できることを示すためで、設 定される値は同しものです。これらの値が必要とされて いる場所には、そのまま $(OBJS) や $ ( 冊 ) としてマ クロの値が使われています。 則述のように、マクロ定義は Makefile のどこに書い てもかまいません。しかし、 Makefile の読みやすさを 考えて、この例のように先頭のほうでマクロ定義をおこ なっておいたほうがよいでしよう。 マクロとしての環境変数 マクロには、 Makefile に記述されていなくても使え るものがあります。その 1 つが環境変数です。 UNIX にログインすると、かならすいくつかの環境変数が設 定されています (C シェルの場合は、 printenv コマン ドで確認できます ) 。また、ユーザーが ~ /. 1 。 g 加など UNIX MAGAZINE 1992.4