Next: Option Table, Previous: Errors, Up: Program Behavior
ユーティリティの挙動をそれを起動した名前に依存させないでください。あ るユーティリティに別の名前をリンクすることは、ときどき有用で、そのこと で何をやるのかを換えるべきでない。
代わりに、動作時のオプションか、コンパイルするときのスィッチか、両方を 別の挙動を選択するために使いなさい。
同様に、プログラムの挙動をそれが使う出力デバイスの種類に依存しないよう にしてください。デバイス独立はシステム設計の重要な原理だ。単に誰かがと きどきオプションを打ち込むのを省略することに妥協してはならない。(端末 を使うときのエラーメッセージの文法を変化させるのは構わない。なぜなら、 それは人々が依存していない別な問題だからだ。)
もし出力が端末に向かうときある挙動が最も有用で、出力がファイルかパイプ なら他の挙動が最も有用なら、端末への出力で有用な挙動をデフォルトにして、 他の挙動のオプションを持つのが通常一番良い。
互換性のために、出力デバイスの種類に依存するプログラムを必要とする。
もしls
やsh
が、あらゆるユーザが期待する方法で働かなかった
ら、それはひどいだろう。これらの場合のうちいくつかでは、出力デバイスの
種類に依存しない、より好ましい別バージョンを我々は補う。例えば、
ls
にとても似ているが、デフォルトの出力形式が常に複数欄形式であ
る、dir
プログラムを提供する。
プログラムのコマンドライン・オプションをposixのガイドラインに従わ
せるのは良い考えだ。これを行う一番簡単な方法は、それらを解析するのに
getopt
を使うことだ。getopt
のGNUバージョンは、特別な引数
‘--’が使われなければ、通常オプションが引数のどこにあっても良いこ
とに注意しなさい。これはposixが規定していることではない。GNUの拡
張だ。
一文字のUnix形式オプションと等価な長い名前のオプションを定義してくださ
い。我々はこの方法でGNUをよりユーザに親しみやすいものにしたいと思って
いる。これはGNUの関数getopt_log
を使えば簡単だ。
長い名前のオプションの利点の一つはどのプログラムでも一貫したものにでき るからだ。例えば、ユーザは“verbose”オプションを持つどのGNUプログラム もそれが正確に‘--verbose’と綴られると期待することができるべきだ。 この不変性を成すために、あなたのプログラムのオプション名を選ぶとき、共 通の長いオプション名の表を見なさい (see Option Table)。
普通の引数として与えられるファイル名が入力ファイルだけにするのは普通良い 考えだ。どんな出力ファイルでも(願わくは‘-o’や‘--output’のよう な)オプションによって指定されるだろう。互換性のために普通の引数として出 力ファイル名を許す場合でも、それを指定する他の方法としてオプションを与え てみなさい。これはGNUユーティリティの一貫性を増し、そしてユーザが覚える べき独自性を減らすであろう。
あらゆるプログラムは次の二つの標準的なオプションをサポートすべきだ。 ‘--version’と‘--help’だ。
--version
最初の行をプログラムが解析しやすくする。そのバージョン・ナンバーを最後の スペースの後に始める。加えて、このプログラムの正しい名前を次の形式で含め る。
GNU Emacs 19.30
プログラム名は固定文字列であるべきだ。それをargv[0]
から計算しては
いけない。その考えは、そのファイル名ではなく、そのプログラムの標
準的、あるいは、正統な名前を表明することである。コマンドをPATH
か
ら見付けることで、正確なファイル名を見付け出す他の方法があるのだ。
もしプログラムが大きいパッケージの補助的な部分なら、次のようにそのプログ ラム名を括弧の中で記述しなさい。
emacsserver (GNU Emacs) 19.30
もしそのパッケージがこのプログラムのバージョン・ナンバーとは違うバージョ ン・ナンバーを持っているなら、閉じ括弧の直前にそのパッケージのバージョン・ ナンバーを記述して良い。
もしこのプログラムを含むパッケージとは別に配布されるライブラリのバージョ ン・ナンバーを記述したいのなら、記述したいそれぞれのライブラ リ毎に行を追加して、バージョン情報を出力することで、そうして良い。それら の行に最初の行と同じ形式を使いなさい。
そのプログラムが使うライブラリ全てを、“単に完全であるためだけに”記述し ないでください。—そうすると、たくさんの役に立たない乱雑さを生み出して しまうだろう。あなたがデバッグをするのに非常に重要であると実際に見出し た場合にだけ、ライブラリのバージョン・ナンバーを記述してください。
バージョン・ナンバーの行の後の、次の行は著作権通知であるべきだ。二つ以上の 著作権通知が必要なら、それぞれ別の行に入れなさい。
次は、そのプログラムがフリーソフトウェアであり、ユーザは自由に複製したり、 ある条件でそれを改変して良いという、簡単な記述が続くべきだ。もしそのプロ グラムがGNU GPLによって保護されているなら、ここでそう言いなさい。また、 法に認められる範囲に対し、無保証であることを書きなさい。
名誉を与える方法として、そのプログラムの主要な作者の名簿を出力して終わら せて構わない。
これらの規則に従う出力の例を示そう。
GNU Emacs 19.34.5 Copyright (C) 1996 Free Software Foundation, Inc. GNU Emacs comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Emacs under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING.
これをあなたのプログラムに一致させるべきだ。当然、適切な年、著作権者、プ ログラムの名前、そして、配布条件の言及を入れ、必要に応じて残りの言葉遣い を換えるべきだ。
この著作権通知は変更がなされた一番最近の年を記述するだけでいい。—以前
のバージョンの変更に対して年を列挙する必要はない。もし不便なら、プログラ
ムの名前をこの通知の中で記述しなくて良い。最初の行に現れているから。
--help
‘--help’オプションの出力の最後の辺りで、バグ報告をどこにメールする かを表す行があるべきだ。こういう書式を持つ。
Report bugs to mailing-address.