Go to the first, previous, next, last section, table of contents.
Cygwin をインストールした後であれば、沢山のドキュメントが `/usr/share/doc/' 以下で見つかるでしょう。 多くのパッケージは標準的な文書と共に提供されており、それらは `/usr/share/doc/パッケージ名' 以下に置かれています。 加えて、幾つかのパッケージでは `/usr/share/doc/Cygwin/パッケージ名.README' というファイル中に Cygwin 特有の説明が書かれています。 他の古いパッケージは、未だにドキュメントを `/usr/share/doc/' ではなく、`/usr/doc/' 内に置いています。
Cygwin プロジェクトの WWW ページである http://cygwin.com/ には、非常に多くのリンクがあります。最低限、メインの Web ページにある「Release Notes」又は「Readme」、或いは「read this」のいずれかは読んでおきましょう。 何か書いてあるかも知れません。
包括的な Cygwin ユーザーズガイドは http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html に、API リファレンスは http://cygwin.com/cygwin-api/cygwin-api.html にあります (1)。
個々の GNU ツールに関するドキュメントは http://www.fsf.org/manual/ で参照することが出来ます(GNU のマニュアルはローカルのミラーで読むべきです。それらのリストについては http://www.fsf.org/server/list-mirrors.html で確認して下さい)。
Cygwin メーリングリストに関する包括的な情報は http://cygwin.com/lists.html で参照出来ます (2)。
メインのメーリングリストに参加するには、cygwin-subscribe@cygwin.com にメッセージを送って下さい。メインのメーリングリストから退出するには cygwin-unsubscribe@cygwin.com にメッセージを送ります。 どちらの場合でも、サブジェクトとメッセージ本文は無視されます。
同様に、Cygwin のアナウンス用のメーリングリストに参加するには cygwin-announce-subscribe@cygwin.com にメッセージを送ります。退出するには cygwin-announce-unsubscribe@cygwin.com にメッセージを送ります。
本プロジェクトに対するボランティアとして Cygwin ライブラリの開発に関わるつもりであれば、cygwin-developers と呼ばれる Cygwin 開発者用メーリングリストに参加したくなるかもしれません。 ライブラリそれ自身よりも、Cygwin ツールやアプリケーションに貢献するのであれば、cygwin-apps に参加すべきでしょう。 参加方法は最初に記述した二つのメーリングリストと同様です。 cygwin-developers と cygwin-apps は承認制のメーリングリストです。
メインのメーリングリストの検索可能なアーカイブは http://cygwin.com/ml/cygwin/ にあります。やはり検索可能な別のアーカイブが http://www.delorie.com/archives/ にあります。検索語に「cygwin」を含めて http://www.google.com/ で検索することも出来ます。
Cygwin メーリングリストは USENET にゲートウェイされていませんので、電子メールアドレスに対する SPAM よけの工夫は必要ありませんし、評価もされません。HTML で記述されたメールも Cygwin メーリングリストには送信しないで下さい。
これらのガイドラインに従えば、Cygwin 開発者又は一般の Cygwin コミュニティからずっと役に立つ反応を得ることが出来るでしょう。
もし上記のガイドラインに従わなければ、反応を引き出すことは出来ても、感謝することはないでしょう。
サポート契約や商用ライセンスに関するお問い合わせについては、 http://www.redhat.com/software/cygwin/ を参照して下さい。
その向こうでは、おそらく誰もあなたの質問に答える時間がないのでしょう。或いは、誰も答えを知らないのかも知れません。
最近アップグレードを行った後で、急に vim(や他の Cygwin アプリケーション)が
「cygncurses5.dll が見つかりません」といって失敗するようになった場合、 あなたは
http://cygwin.com/ml/cygwin-announce/2001/msg00124.html
に示された手順に正しく従っていません。 この問題を解決するためには、Cygwin Setup を再度実行して
`libncurses5' を再インストールする必要があります。
デフォルトでは、Cygwin Setup はこのオプションを示さないことに注意して下さい。 「Select packages to install」ダイアログで `Full/Part' ボタンをクリックします。これによって、 既にインストール済のものも含めて全パッケージが表示されます。 下へスクロールして `libncurses5' を探し出し、 「Reinstall」と表示されるまで「回転」記号をクリックし、 インストール作業を継続します。
同様に、もし何らかのパッケージが「cygintl.dll が見つかりません」といった場合、Cygwin
Setup を実行して `libintl' と
`libintl1' パッケージを再インストールして下さい。
一般的な問題に関する詳細な説明、そしてこの問題を(cygreadline5.dll のような)他の「見つからない」DLL に展開する方法、 そしてそれらの DLL が含まれているパッケージを探し出すには、 http://cygwin.com/ml/cygwin/2002-01/msg01619.html を参照して下さい。
つい最近 `cygwin' パッケージをアップグレードした後で、
全てのコマンドの実行に非常に長い時間がかかるのであれば、 恐らく既に過去のものとなった
//c 記法が PATH 中に含まれていることでしょう。
現在では、この記法はネットワーク共有 c
を意味します。そしてそのような共有が存在しない場合、 途方もなく遅くなってしまいます。次の FAQ エントリを参照して下さい。
(例えば Z: に対する //z のように、
全てのドライブ文字に対して当てはまります)
この「機能」は長い間非難されてきており、 今後の全ての最新版リリースにおいて、もはや動作しません。 リリース 1.3.3
では、//c は ネットワーク共有 c を意味します。
なぜこのような変更が行われたかに関する詳細な議論について、 そして今ではどのように取り扱われるかについては、 http://sources.redhat.com/ml/cygwin/2001-09/msg00014.html を参照して下さい。
setup.exe によって作成される /etc/profile で全ての設定は完了しています。
このファイルはデスクトップ又はスタートメニューから bash を起動した際に読み込まれ、その内容は以下のようになっています。
PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
実際のところ、この設定は /usr/local/bin と /usr/bin を Windows
システムのパスへと追加します。 もし PATH をリセットしたいのであれば、以下のルールに従って
$HOME/.bashrc に設定するか、又は直接 /etc/profile を編集して下さい。 PATH
の設定時には、/usr/bin を全ての Windows
システムディレクトリの前に設定する必要があります (そして
Windows システムディレクトリを省略してはなりません!)。 そうしなければ、おそらく Cygwin
アプリケーションの実行時にあらゆる問題に遭遇することになります。
プログラムをコンパイルしたのに、 それが実行できないように見えるかもしれません。
bash$ gcc -o hello hello.c
bash$ hello
bash: hello: command not found
Windows とは異なり、デフォルトでは bash はプログラムを `.'(カレントディレクトリ)からは探しません。 PATH(上記を参照)に `.' を追加することも出来ますが、 セキュリティ上の理由から、(少なくとも UNIX では)推奨されません。 bash にどこから探すかを伝えるには、 コマンドライン上でこのようにタイプします。
bash$ gcc -o hello hello.c bash$ ./hello Hello World!
「cypath」ユーティリティを使用します。 使用方法を知るためには、cygpath --help
を実行します。 例えば(私の環境では)、
bash$ cygpath --windows ~/.bashrc D:\starksb\.bashrc bash$ cygpath --unix C:/cygwin/bin/cygwin.bat /usr/bin/cygwin.bat bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat /usr/bin/cygwin.bat
bash が「\」をエスケープキャラクタとして扱うことを覚えておいて下さい。 そのため、「\」を認識させるには bash シェル上で二回タイプする必要があります。
.bashrc は環境変数 HOME が示すホームディレクトリから読み込まれます。 HOME が設定されていない場合は /.bashrc が読み込まれます。 正しく HOME を設定するか、.bashrc を Cygwin の / としてマウントされたドライブの最上位に移動する必要があります。
~/.bashrc ファイルに以下を追加して下さい。
shopt -s nocaseglob
また、~/.inputrc ファイルに以下を追加して下さい。
set completion-ignore-case on
Cygwin はファイル名やパス名の中のスペースはサポートしません。 つまり、このライブラリを使ったユーティリティは動かないかもしれない、 ということです。通常、UNIX ではファイルにスペースは含まれないからです。 もしあなたがこの問題に引っかかってしまったら、 そのユーティリティを修正するか、 Cygwin ツールでスペースのあるファイル名を使うのをやめるかするしかありません。
特に、bash はスペースを単語の区切りとして認識します。 スペースを含んだファイル名はクォートするか、 スペース文字をエスケープする必要があります。例えば、
bash-2.03$ cd '/cygdrive/c/Program Files'
又は、
bash-2.03$ cd /cygdrive/c/Program\ Files
のようにします。
これはバージョン 1.3.0 未満のバージョンに対してのみ有効です。
Cygwin は Windows Explorer ショートカット(*.lnk ファイル)を辿りません。 ショートカットは通常のファイルとみなされるので、その中には「cd」出来ないのです。
中には現在のシンボリックリンクの仕組みをショートカットで置き換えることを提案する人もいます。 これに関する一番の問題は、Cygwin パスのシンボリックリンクを使った .LNK ファイルは、Explorer などのような非 Cygwin の Win32 ネイティブアプリケーションにとっては、正しいかもしれないし、正しくないかもしれないということです。
バージョン 1.3.0 以降、Cygwin はショートカットをシンボリックリンクとして扱います。
Cygwin ツールに付属している find を使っていること、つまり間違って Win32 の find コマンドを使っていないことを確認して下さい。 正しいものを使っていることを確認するには、bash から「type find」を実行します。
find に対するパス引数(デフォルトではカレントディレクトリも含む)それ自身がシンボリックリンクである場合、find は `-follow' オプション (3) が指定されない限りそれを参照しません。 この動作は他の多くの UNIX の実装とは異なりますが、これは変更されそうにはありません。
満足のいく結果が得られないように思われる場合、或いは幾つかのディレクトリが見つからない場合、find による最適化に付随する問題に遭遇したのかもしれません。 DVD-R UDF のような、`.' や `..' が欠如したファイルシステムでは、find は正しく動作しません。 マニュアルページでオプション `-noleaf' の説明を調べてみて下さい。
かつて存在した `su' は一旦 Cygwin ディストリビューションから外されており、Cygwin に移植されることも、動作することもありません。現在は sh-utils の一部として再びインストールされるようになりましたが、動作しません。
代わりに `login' を使うことが出来ますが、まず最初に http://www.cygwin.com/ml/cygwin/2001-03/msg00337.html を読んで下さい。
`su' が動作しない技術的な背景については、 http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html 及びリリースメッセージを参照して下さい。
`man' パッケージをインストールした後でさえ、このようなエラーを受け取ることがあります。
bash-2.04$ man man Error executing formatting or display command. System command (cd /usr/man ; (echo -e ".pl 1100i"; cat /usr/man/man1/man.1; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -is) exited with status 32512. No manual entry for man
`ash' パッケージに含まれている /bin/sh が必要ですので、これもインストールしなければなりません。
更に、`man -k' 又は `apropos' を利用する前に whatis データベースを作成しておく必要があります。 これには以下のコマンドを実行します。
/usr/sbin/makewhatis
(完了するまでには少し時間がかかります)
`ntsec' は Windows NT の NTFS ファイルシステム上で UNIX パーミッションを実現します。 (最近の変更によって)これはデフォルトになっています。
`ntea' は NTFS 及び FAT 上で動作しますが、 FAT ファイルシステム上では巨大で削除出来ないファイルを生成します。
(`ntsec' 及び `ntea' は環境変数 `CYGWIN' に設定する値です。 この変数と設定方法についての更なる情報は、 http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html にある Cygwin ユーザーズガイドを参照して下さい。)
全ての Windows 9x では対応出来ません。
もしファイルに対して特定のパーミッションを要求するアプリケーションがあるなら、 アプリケーションのソースコードを修正することでこの問題を回避することが出来るかもしれません。 Corinna Vinschen による OpenSSH に対する変更がヒントになるでしょう。 Cygwin メーリングリストのメッセージ http://cygwin.com/ml/cygwin/2000-11/msg01176.html を参照して下さい (4)。
不幸なことに、このようなことは出来ません。
bash$ mkdir -p //MACHINE/Share/path/to/new/dir mkdir: cannot create directory `//MACHINE': No such file or directory
mkdir はパス中の個々のディレクトリの存在を確認し、必要であればそれを作成するからです。 `//MACHINE' はディレクトリではありませんが(そこへは cd 出来ません)、mkdir はそれを作成しようとし、そして失敗します。
いつかは修正されるかもしれませんが、今のところはこのようにする必要があります。
bash$ cd //MACHINE/Share bash$ mkdir -p path/to/new/dir
実行するには二つの本質的な問題があります。 一つは、/bin/sh は実際には ash であり、特に /bin/sh を bash(Linux) や ksh(Tru64) と見なして利用しようとした場合には、/bin/sh に期待される幾つかの機能が欠けているからです。例えば、
或いはパーミッションの問題であり、Cygwin はあなたのスクリプトを実行形式だと認識しなかったのでしょう。 `chmod' が動作しないので(FAQ の上記項目を参照)、Cygwin はスクリプトが実行可能かどうかを、ファイルの内容を読んで判断しなければなりません。もしあなたのスクリプトが
#! /bin/sh
で始まっていなければ(或いは /bin/sh に限らず、任意のスクリプトのインタプリタ)、Cygwin はそれが実行可能なスクリプトであることを知ることが出来ません。Bourne シェルの慣用法である
: # これは 2 行目で、/bin/sh が処理することを仮定しています。
もまた有効です。
`mount -x' を使えば、Cygwin はマウントポイント以下の全ファイルを実行可能として取り扱うということを覚えておいて下さい。 これはディレクトリだけでなく、個々のファイルのために使用されます。 そして Cygwin はそれらが実行可能であるかどうかを判定するためにわざわざファイルを読み込みません。
UNIX 上に存在する lp や lpr システムは動作しません。
Jason Tishler は(テキストを正しく PostScript に整形する) a2ps と (PostScript ファイルを PostScript 非対応の Windows プリンタで印刷する) ghostscript の利用方法について説明した二通のメッセージを書きました。 http://cygwin.com/ml/cygwin/2001-04/msg00657.html から始めましょう。`file' コマンドは現在、Cygwin セットアップの一部分として利用可能になっていることに注意して下さい。
NT 上では代わりに、Windows の `print' コマンドが利用出来ます(これは Win9x 上では動作しないようです)。
bash$ print /\?
をタイプすれば利用方法が表示されます(`?' をシェルからエスケープする必要があることに注意して下さい)。
最後に、ファイルをプリンタの共有名に対して単純に `cat' することも出来ます。
bash$ cat myfile > //host/printer
プリンタの用紙送りボタンを押すか、用紙送り文字をファイルに追加する必要があるかもしれません (5) 。
bash 上で国際化文字をタイプする前に、 以下の行を ~/.inputrc
ファイルに追加しなければなりません (6) 。
set meta-flag on set convert-meta off set output-meta on
これらは readline ライブラリに対するオプションです。 詳細については
bash(1) 及び readline(3) の man ページを参照して下さい。
less や ls のような、readline を利用していない他のツールで 8
ビット文字を表示させるには、追加の設定が必要です。 ~/.bashrc
に以下の内容を記述して下さい。
alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars'
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
慎重な実験によって、カーソルキーが実用的ではなく、むしろ奇妙に振舞うことが分かります。 例えば、NumLock がオフであれば、数値キーパッドのキーは通常のカーソルキーを押すまで動作しますが、個々の数値キーが動作しないときに数値/文字キーを再度タイプすれば、カーソルキーは再び動作し始めます。 この現象は Win98 と Win95 の地域化バージョンで発生すると報告されており、Cygwin に特有のものではありません。これらは Alt+Enter(フルスクリーン/ウィンドウの切り替え)が動作せず、他のプログラムに移り続けるという問題として知られています。 この問題の原因は、デフォルトで「autoexec.bat」にインストールされる Microsoft のキーボードローカライザです。このような行がそうです(これはロシア語用ロカールです)。
keyb ru,,C:\WINDOWS\COMMAND\keybrd3.sys
キーを正しく動作させるためには、このような行をコメントアウトする必要があります。 勿論、これは使用している各地域用のアルファベットキーボードのサポートを剥奪するため、他のローカライザを使用することを考える必要があるでしょう。 例えば、ロシアのユーザは勿論 Keyrus ローカライザのことを知っていますし、キーボードエディタを使用すればそれは他のロカールででも動作するでしょう。しかし、それにはロシア語メッセージと文書しかありません ;-( 参考となる URL は http://www.hnet.ru/software/contrib/Utils/KeyRus/ です(Keyrus を正しく動作させるためには、Windows ロゴ表示を切る必要があるかもしれません)。
システム内には Cygwin DLL のコピーは一つだけにしておくべきです。 複数のバージョンが存在する場合、衝突して問題を起こすことでしょう。
「shared region is corrupted(共有領域が汚染されている)」又は 「shared region version mismatch(共有領域のバージョンが合致しない)」 というエラーが出た場合、複数のバージョンの cygwin1.dll が同時に動作していることを意味します。 例えば、あらかじめ全ての Cygwin アプリケーション(inetd を含む) を終了させずに cygwin1.dll をアップデートしたような場合、 この事態が発生します。
DLL がまだメモリ中にロードされているということが原因ですので、 この問題を起こす複数のバージョンの DLL を発見するには、 まずリブートします。続いて、Windows システムの検索ユーティリティを使い、 PATH(「type」が使用します)に含まれている部分、 又は Cygwin がマウントしているファイルシステム (Cygwin の「find」が使用します)だけでなく、 マシン全体を検索します。
「more」ページャを探しているのであれば、 その代わりに「less」ページャを使いましょう (7)。
恐らく、誰もそれをメンテナンスしていないからでしょう。 それは時間がかかる作業ですし、Cygwin チームの最優先事項は Cygwin パッケージです。残りはボランティアの努力によるものです。 協力したいですか? それでは以下を参照下さい。
幾つかの柔軟性があります。
Cywin はマウントされていないドライブ用に、組込みの「cygdrive プレフィックス」を備えています。 任意のドライブ、例えば Z: の場合は「/cygdrive/z/」でアクセス出来ます。
幾つかのアプリケーション(特に bash)では、Windows のバックスラッシュ(「\」)の代わりに POSIX のスラッシュ(「/」)を使って、慣れ親しんだ Windows の <drive>:/path/ が使用できます (しかし以下の警告を参照して下さい!)。 これは分かりきった方法での Windows パスへのマップですが、しかし内部的には以下の(デフォルト、又は明示的な)マウントに従って、Cygwin パスを使用するために変換されています。 デフォルトの設定では、例えば、
bash$ cd C:/Windows bash$ pwd /cygdrive/c/Windows
そして
bash$ cd C:/cygwin bash$ pwd /
です。Windows パスにバックスラッシュも使用できますが、それらはシェルからエスケープされねばならないでしょう。
警告: 異なるマウントポイントを経由した異なる POSIX パスが同じ Windows ディレクトリへとマップされ得るため、Windows パスを POSIX パスに変換する際には幾つかの曖昧さが存在します。 異なるマウントポイントがそれぞれ binmode 又は textmode であることがあり、Cygwin アプリケーションの動作はここで得られる POSIX パスに非常に依存したものであるため、これは問題になります。
POSIX パスへのマウントされたドライブを明確化することで、この Windows パスの曖昧さと、「/cygdrive」とタイプすることを避けることが出来ます。 例えば、
bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c
これにより、`/cygdrive/c/Windows' はよりタイプ量の少ない `/c/Windows' になります。
ドライブのマウントは一回だけ必要であることに注意して下さい。 マッピングはレジストリに保持されるので、マウントはほぼ無期限で有効です。 umount、又はレジストリエディタだけがマウントを削除します。
mount への「-b」オプションは、テキスト及びバイナリファイルを同等に扱う バイナリモード(「binmode」)でマウントします。 これは open 呼び出しにバイナリフラグが付与されていない、悪い移植がなされた UNIX プログラムに対してのみ必要です。 デフォルトの Cygwin のインストールでは、/、/usr/bin そして /usr/lib もこの設定になっています。 新しいマウントへのデフォルトはテキストモード(「textmode」)であり、全ての「cygdrive」マウントのモードもそうなっています。
デフォルトの `cygdrive' プレフィックスと、それが binmode 又は
textmode のどちらを使用するのかは、mount
コマンドを使用して変更することが出来ます。例えば、
bash$ mount -b --change-cygdrive-prefix cygdrive
は /cygdrive/... マウントを binmode へ変更します。
まず、標準のコンソールウィンドウの代わりに rxvt を利用することを検討して下さい。 rxvt では、左マウスボタンで選択することによってコピーが、中央のマウスボタンでペーストが出来ます。 なんて簡単なんでしょう!
Windows NT では、コンソールウィンドウのプロパティダイアログを開きます。 「簡易編集モード」のトグルボタンがありますので、それを ON にしてプロパティを閉じます。
Windows 9x では、コンソールウィンドウのプロパティダイアログを開きます。 「その他」タブを開き、「高速ペースト(Fast Pasting)」のチェックを外し、「QuickEdit」をチェックします。
.inputrc ファイルに以下の行を追加すれば、クリップボードからペーストするための機能を insert キーにバインドすることも出来ます。
"\e[2~": paste-from-clipboard
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
通常、これは既ににマウントされている場所に更にマウントしようとしているという意味です。 例えば、c: が「/」にマウントされているとして、d: を同じようにマウントしようとするとこのエラーメッセージが出ます。 まず古いものを「umount」して、それから新しいものを「mount」すればよいでしょう。
もし '/' を umount
しようとしたときにこのメッセージが出たのであれば、regedit.exe を起動して
HKEY_CURRENT_USER/Software/Red Hat, Inc./CYGWIN.DLL
setup/<version> の下に保持されているマウントポイントの中から、
「/」マウント用の「native」キーを変更する必要があるかもしれません。 ここで <version> は、Cygwin
ライブラリに関連付けされている最新の登録バージョンを指します。
開発中、我々は Samba の動いている UNIX マシンと NT/Windows 95/98 マシンの両方を使っています。 しばしば、UNIX 上のクロスコンパイラを使ってビルドしてバイナリとソースを Windows システムにコピーしたり、又は単に Samba でマウントされたパーティション上で直接いじくりまわしたりしています。 NT/Windows 9x のデュアルブートマシン上では Windows 9x 上からもアクセスできるように、通常は FAT ファイルシステムを使用しています。
いくつかの UNIX プログラムは、同じ綴りのファイル名を大文字 / 小文字を変えて使い分けることが出来ることを期待しています。 大きな例としては perl のコンフィグレーションスクリプトがあり、これは Makefile と makefile を必要とします。 Win32 はただ大文字 / 小文字が異なるだけの両ファイルを区別出来ないため、コンフィグレーションは失敗します。
beta 16 以前のリリースでは、mount にはファイル名を変更して大文字 / 小文字ファイル名を使い分けられる、特別な mixed case オプションがありました。 私たちはこのサポートを、beta16 のパス操作コードを書き直すときに削除することに決めました。 標準の Windows アプリケーション -- explorer.exe、cmd.exe/command.com など -- は大文字 / 小文字だけの違いだけではファイル名の違いを区別しません。 結果として幾つかの(重大な)望まざる動作が生じます。
Sergey Okhapkin は B20.1 まで mixed-case パッチ(「coolview」)を保守していましたが、これは最近のバージョンの Cygwin 用にはアップデートされていません。
ファイル名として(幾つか例を挙げれば) com1、lpt1、aux は使えません。 ファイル名の基幹部分としても、拡張子部分としてもです。 もし使ってしまうと面倒が起きるでしょう。 UNIX プログラムはこれらの名前を避けるような楽しいことはしてくれません。 例えば、 perl のディストリビューションの中には aux.sh というファイルがあります。perl のコンフィグレーションでは aux.sh ファイルが存在することを確認しようとしますが、「aux」という魔法の文字が含まれているファイルを操作しようとしてハングしてしまうでしょう。
何かがおかしくなって、何らかの理由でツールが帰ってこなくなった場合(aux.sh というファイルを読んでみれば簡単にこの状態になります)、まず ^C を叩き、bash あるいは cmd プロンプトに戻ってみて下さい。
別のシェルを起動してもアプリケーションが動かないのであれば、暴走したプロセスがまだどこかで動いてると考えるべきです。 タスクマネージャ、pview、或いは同様のユーティリティを使ってそのプロセスを殺して下さい。
そして、もし全てが失敗したとしても、リセットボタン / 電源スイッチはいつでもあります。 これは Windows NT では必要ないはずですが。
なぜ /lib と /usr/lib (そして /bin と /usr/bin)が同じものを指しているのでしょうか?
なぜシンボリックリンクの代わりにマウントを使用するのですか?
(C:\ のような)ディスクルートを Cygwin のルートとして使用できますか? なぜそれは禁止されているのですか?
デフォルトの場所に新規にインストールした直後は、マウントポイントは以下のようになっています。
bash$ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode)
(厳密には、これは setup.exe に対して与えたオプションに依存します)
/bin と /usr/bin、/lib と /usr/lib が同じ場所を示していることに注意して下さい。 これは内部的なものであり、自分が何をしているのかについて本当に理解していない限り、これを変更するべきではありません。
様々なアプリケーションとパッケージは /lib 又は /usr/lib(/bin 又は /usr/bin も同様)がインストールされていることを期待しています。 それらの間の区別、そしてそれらに絶えず注意を払うよりも(もしかすると、時々複製やシンボリックリンクが必要となるかもしれません)、 同じ方法でアクセス出来るたった一つの実在のディレクトリをメンテナンスすることに決めました。
この目的のためにシンボリックリンクを使用することも考えましたが、Samba ドライブ上では常に正しく動作するわけではないので、この案は却下されました。 マウントを解決する際にディスクアクセスは必要ないため、マウントはより高速であるというのも理由です。
非 Cygwin アプリケーションは Cygwin のマウントを検知しないことに気をつけて下さい(シンボリックも同様)。 例えば、仮に Cygwin パッケージの tar 配布物を展開するために WinZip を使用したとしても、正しい Cygwin パスへとはインストールされないでしょう。 そのようなことは行わないで下さい!
何を行っているのかを知らないのであれば、そしてその結果に対する心構えがないのであれば、ドライブのルートディレクトリと Cygwin のルートディレクトリを同一にしないことを強くお奨めします。 例えば C:\ から Cygwin のファイル階層を分離しておくことは、一般的に Cygwin のファイル階層を管理しやすくします。 第一、(例えば) \bin や \lib を作成する他の(非 Cygwin)アプリケーションとの起こりうる衝突を避けられます(そのようなアプリケーションを今はインストールしていなくとも、将来的にインストールしないと誰が言えるでしょうか?)。
ある方の報告では、 NT 用(他のものもか?)の NAI(以前は McAfee) VirusScan は Cygwin とは相容れないとのことです。 cygwin.dll の中で新しくロードされた共有メモリをスキャンしようとするため、結果として fork() が失敗し、多くのツールに大破壊をもたらします。
NAI VirusScan のせいで、tar.gz アーカイブを展開する際にシステムがハングするという報告が幾つもあります。 これは恐らく VirusScan のバグであり、NAI に対して報告されるべきでしょう。 正しく動作させる唯一の方法は、これらのファイルにアクセスする際に VirusScan を無効にしておくことです。 これはセットアップの際に問題となるかも知れないので、FAQ の項目中でも議論されています。
何人かのユーザは、それらのアンチウィルスソフトウェアが有効になっていると、Cygwin
の使用中に重大なパフォーマンス低下が発生すると報告しています。
完全にアンチウィルスソフトウェアを無効にしてしまうよりも、特定のディレクトリの内容をスキャンしないように指定するほうがよいでしょう。
デフォルトのインストールでは `C:\cygwin\bin'
に相当します。 悪意のある 非 Cygwin プログラムから利用され得るのは明らかですので、自己責任でお願いします。
はい! X11 (`http://cygwin.com/xfree/')の Windows インタフェースで利用出来ます。 リモートログインシェルからであれば、「emacs -nw」が正しく動作します。 非 X11 バージョンの Emacs もまた、テキストのみのターミナルインタフェース用に用意されています。 いずれ(或いはその両方)も、Cygwin Setup を利用してインストールすることが出来ます。
X を利用せず、ネイティブの Microsoft Windows のインタフェースを利用して GNU Emacs を利用したいのであれば、一般的に「NT Emacs」として知られている Emacs の Windows 移植版を利用する必要があります。NT Emacs は GNU のミラーサイトから入手可能です。 これを Cygwin Setup から取得することは出来ません。
NT Emacs は、デフォルトでは Windows のコマンドシェルを使用します。 Emacs は Cygwin アプリケーションではないので、Cygwin のマウントについては関与しません。 これらの点を念頭において、bash を使用するためには以下のコードを ~/.emacs(又は ~/_emacs)に記述する必要があります。これは特に JDEE パッケージ( http://jdee.sunsite.dk/ ) を使用するために有用でしょう。以下の設定は Emacs 21.1 用のものです。
;; Cygwin は C:\cygwin(デフォルト)にインストールされており、
;; C:\cygwin\bin が既に Windows パスに含まれていないことを
;; 仮定しています(一般にはそうではない筈ですが)。
;;
(setq exec-path (cons "C:/cygwin/bin" exec-path))
(setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH")))
;;
;; NT-emacs は、ここで変更する Windows コマンドシェルを
;; 使用します。
;;
(setq process-coding-system-alist '(("bash" . undecided-unix)))
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
;;
;; これは、Java アプリケーションの出力に出現する
;; 見苦しい ^M 文字を削除します。
;;
(add-hook 'comint-output-filter-functions
'comint-strip-ctrl-m)
もし NT Emacs に Cygwin パスを理解させたいのであれば、cygwin-mount.el を http://www.emacswiki.org/elisp/index.html から手に入れて下さい。
XEmacs の現在の状態に関する簡単な説明については、Cygwin メーリングリストに流れた `http://cygwin.com/ml/cygwin/2002-11/msg00609.html' の内容を参照して下さい。
はい! 代わりに rxvt を利用して下さい。これは Cygwin Setup で入手可能なオプショナルパッケージであり、X11 なしでも利用可能です。 ウィンドウの端又は角をドラッグすることによって簡単にサイズを変更することが出来ますし、マウスの左及び右ボタンをそれぞれ利用することによって、簡単にコピーとペーストを行うことが出来ます。 rxvt は X こそ利用しませんが、~/.Xdefaults の設定は利用します。
単純に「rxvt」を起動することは避けて下さい。なぜなら、rxvt は対話的シェルとしてはあまり良くない
/bin/sh(実際には ash)を起動するからです。 詳細については
/usr/share/doc/Cygwin/rxvt-<バージョン>.README
を参照して下さい。
Cygwin パッケージはそのパッケージの info ドキュメントを /usr/share/info
ディレクトリにインストールします。 しかし、事前にそのディレクトリ中に、スタンドアロンの info プログラム(恐らく
/usr/bin/info) がそれらの info ファイルを読む際に使用する
dir ファイルを作成しておく必要があります。このようにします。
bash$ cd /usr/share/info bash$ for f in *.info ; do install-info $f dir ; done
このような警告が出るでしょう。
install-info: warning: no info dir entry in `gzip.info' install-info: warning: no info dir entry in `time.info'
install-info コマンドはこれらのファイルをパース出来ないので、
それらのエントリについては手で /usr/share/info/dir
に追加しなければならないでしょう。
dir ファイルが既に存在したとしても、新しい Cygwin パッケージをインストールしたならば dir ファイルを更新する必要があります。 幾つかのパッケージはあなたに代わって dir ファイルを更新してくれますが、大部分のパッケージはそんなことはしてくれません。
「Out of queue slots!」は通常、削除する権限のないファイル(パーミッションがない、排他的に使用中である、など)を数多く消去しようとしたときに発生します。 何が起こるかというと、Cygwin はこれらのファイルは後で削除出来るようになるであろうという仮定のもとに待ち行列に入れてしまうのです。 そのファイルのパーミッションが後で変更されたとすると、そのファイルは要求通りに削除されるでしょう。 しかし、アクセス出来ないファイルを削除する要求があまりに数多く発生するとキューが溢れてしまうので、質問のメッセージが発生するのです。 通常は、すぐに chmod する、ファイルを閉じる、などによって対処することが出来ます(Larry Hall 氏に説明を頂きました。感謝します)。
シンボリックリンクには「system」ファイル属性が付与されますが、デフォルトでは samba はこの属性をサポートしていません。 これを有効にするには、Samba のドキュメントを参照し、Samba の設定ファイルに以下の行を追加して下さい。
map system = yes create mask = 0775
0010 ビットが設定されている限り、0775 は何でもあるかもしないことを覚えておいて下さい。
Win32 API 関数の GetFreeDiskSpace にはバグがあり、 2 GB 以上の大きさのディスクに対して誤った値を返してきます。 おそらくこれが問題なのではないでしょうか?
Cygwin と共に配布されている Tcl/tk のバージョン(例えば cygtclsh80.exe や
cygwish80.exe)は、実のところ Tcl/tk の「Cygwin 版」ではありません。これらは
gcc に `-mno-cygwin'
オプションを与えてコンパイルしたものです。これはつまり、Cygwin
のマウントやシンボリックリンクを理解しないということを意味します。
本 FAQ の「Windows パスと UNIX パスを変換するにはどうすればよいのですか?」の項を参照して下さい。
UNIX スタイルの API を提供する C のライブラリがあります。 アプリケーションがそれとリンクされると…Windows 上で動きます。
目標は、アプリケーションを Windows で動かすために必要な全ての行儀の悪いものを、C ライブラリに追加することです。 そうすればあなたのアプリケーションは、ソースレベルでの変更無しに UNIX ででも Windows ででも動作するでしょう。
この C ライブラリは DLL 内にあるので、基本的なアプリケーションはとても小さくなります。 また、DLL の変更時に後方互換性を残すことによって、Win32/UNIX 変換層を比較的容易にアップグレードできます。
Cygwin の良き概説として、1998 年 8 月に行われた第 2 回 Usenix NT シンポジウムに際して Usenix Association から発行された Cygnus の論文を読んでみるとよいかもしれません。 これは Cygwin プロジェクトの WWW サイトから HTML 形式で入手可能です。
はい。Cygwin ライブラリ中に何か関心を惹くことが起こった時点で作られます(どれだけ進んだかにもよりますが、通常、おおまかには日次でです)。 これは主に、このプロジェクトにコードを寄贈しようとする方々のためのものです。 バグだらけのスナップショット内の問題をデバッグすることに興味がなければ、これを避けて本当のリリースを待ってください。 このスナップショットは http://cygwin.com/snapshots/ から取得できます。
まずはその背景から説明しましょう。
UNIX ではファイルはファイルであり、ファイルにはプログラム/プログラマ/ユーザが「入れろ」と言ったものは何でも入ります。 Windows においてもやはりファイルはファイルですが、そのファイルの内容はプログラム/プログラマ/ユーザだけでなく、ファイルの処理モードにも依存します。
テキストモードで処理を行われている時は、ある種のデータは特別な扱いをうけます。 \n(改行)がファイルに書かれるとその前に \r(復帰)がぶら下げられるので、例えば printf("Hello\n")としたとすると、実際に得られるのは「Hello\r\n」となります。 この組み合わせを読み込むと \r が削除され、read によって返されるバイト数は実際に読み込まれた数より 1 小さくなります。 この結果、 ftell() や fseek() に依存しているブログラムに混乱を引き起こすことがあります。 ファイルの読み込み中に Ctrl-Z が出現すると、たとえそれが本当のファイルの終端でなくても、ファイルの終端(End Of File)のフラグを設定します。
Cygwin の目的の一つは、Cygwin に移植された UNIX プログラムと一般の Windows プログラムとを簡単に混在できるようにすることです。 結果として Cygwin は、普通に Windows を使用しているときと同様に、ファイルをテキストモードでオープンします。 附属のツールでは、バイナリを扱うツール(objdump など)は UNIX 風のバイナリモードで操作し、テキストファイルを扱うツール(bash など)はテキストモードで操作します。
マウントのオプションや CYGWIN 環境変数の設定によって、デフォルトの処理モードをグローバルにバイナリモードに設定しよう、 という考えを押し進める人もいます。しかしこれは別の問題を生み出します。 バイナリモードでは、プログラムはファイルの中のデータを、\r も含めて全て受け取ります。 プログラムはこれらの属性を特別扱いすることはなくなるので、特にスクリプトや起動時のリソースファイルといったテキストファイルからは \r を自分で取り除かねばならないでしょう。 これは移植者の「責任逃れ」であり、移植者の代わりにユーザが \r の面倒をみなければならなくなってしまいます。
open/fopen 関数が適切なファイル処理モードを与えるように、移植者がソースコードを修正する方がずっと簡単です。
テキストファイルはテキストとして扱い、バイナリファイルはバイナリとして扱うのです。 さらにはっきり言えば、open
呼び出しの第二引数に O_BINARY を追加するか、fopen 呼び出しの第二引数に
"b"
を追加することによってバイナリモードを選ぶことができます。或いは、setmode (fd,
O_BINARY) を呼び出すことでもできます。
この open/fopen へのスイッチは ANSI で定義されているので、これらは殆どの種類の UNIX にも存在するということも憶えておいてください。 UNIX ではこれらのスイッチは無意味ですので、open/fopen はそれを単に無視するだけです。
メーリングリストでの Earnie Boyd 氏 <earnie_boyd@yahoo.com> のメールを基に説明しました。
はい。そうです。
「POSIX スレッド」に対する広範囲ののサポートもあります。 提供されている POSIX
スレッド関数のリストについては、cygwin.din ファイルを参照して下さい。
Windows 9x: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. (8)
しかし本当のところ、Windows 9x には殆どのセキュリティ関連の関数がなく、Win32 API の 1 バージョンとしては足りないものが他にも幾つかあります。 Win 9x において何がサポートされていないかについての情報は、calls.texinfo を参照してください。
Cygwin の fork() は、本質的に「non-copy on write」方式(古い UNIX のバージョンで取られていた方式)の fork() のように動作します。このため、多少遅いです。多くの場合、可能な限り spawn の類の呼び出しは使用しないほうが良いです。
fork() はこのように動作します。
親は、子のための Cygwin プロセステーブル領域を初期化します。 親は Win32 の CreateProcess に自分が起動されたときと同じパスを与えて、中断した子を生成します。 親は setjmp を呼び出してコンテキストを保存し、このポインタを Cygwin の共有メモリ領域にセットします(この領域は全ての Cygwin タスク間で共有されてます)。 親は子の .data と .bss サブセクションを、自分のアドレス空間から中断した子のアドレス空間へとコピーして埋めます。 そして親はその子を開始させます。親はミューテックス (9)を使用して、子が安全な地点に来るまで待ちます。 子は開始して fork されたのがわかったら、保存されたジャンプバッファを使って longjump します。 子は親が待っているミューテックスをセットし、そして親がスタックとヒープを埋めてくれるまで、別のミューテックス上でブロックします。 親は子が安全な領域に入ったことを知ってから、スタックとヒープを自分のものから子の中へコピーし、子が待っているミューテックスを解放して fork 呼び出しから戻ります。 子はブロックしているミューテックスから起きて、共有領域を通して渡された mmap 領域を再作成して、fork 自身から戻ります。
DOS スタイルのプロンプトから起動されたと DLL
が判断した場合、与えられたコマンドラインに対してファイル名の展開を実行します。 これはつまり、DOS から LS
*.EXE とタイプした場合、あなたが期待しているであろう動作を行う、ということです。
注意: ファイル名展開は malloc を使用します。 あなたのアプリケーションが
malloc を定義している場合、それが使用されます。 これはあなたにとっては恐ろしいことかもしれません
(10)。
Cygwin にはシンボリックリンクを作成するための二つの方法があります。
古い方法はバージョン 1.3.0 未満のバージョンに対してのみ有効です。 (1.3.0 以降では CYGWIN 環境変数に「nowinsymlinks」を設定することにより)この方法が有効であれば、Cygwin は魔法のヘッダ(magic header)を持つリンクファイルを生成します。 どこかへとリンクされているファイルまたはディレクトリをオープンすると、その魔法のヘッダに書かれているファイルまたはディレクトリをオープンします。シンボリックリンクかどうかを確認するために毎回全てのファイルをオープンしたくはないので、Cygwin はシステム属性でシンボリックリンクの印をつけます。 システム属性のついていないファイルはチェックされません。 リモートの samba ファイルシステムはシステム属性をサポートしていないので、システム属性を明確に有効にしていない限りネットワークドライブではシンボリックリンクは動作しません。
Cygwin バージョン 1.3.0 と共に導入された新しい方法は、デフォルト、或いは環境変数 CYGWIN に「winsymlinks」が設定されている場合に有効となります。 この方法を利用すると、Cygwin は Windows ショートカットを作成することでシンボリックリンクを生成します。 Cygwin は(Explorer が決して作成しないような)特別なヘッダを持ったショートカットを作成し、読み取り専用属性を設定します。通常、DOS パスはショートカットに格納され、記述エントリ(description entry)は POSIX パスを格納するために利用されます。 POSIX パスがこのように格納されている場合、DOS パスが有効なパスとなるように組替えることが必要となることがあります。 この処理はシンボリックリンクがマウントポイントを跨いで移動させられた際に、DOS パスと POSIX パスの間で相違が生じることにより発生します。 Cygwin ショートカットは「ls」の出力中では「.lnk」拡張子なしで表示されますが、非 Cygwin ショートカットは拡張子付きで表示されます。しかし、両者ともシンボリックリンクとして扱われます。
古いシンボリックリンクと新しいシンボリックリンクは平和的に共存出来ます。 Cygwin は環境変数 CYGWIN 中の「(no)winsymlinks」設定とは無関係に、両者をシンボリックリンクとして扱うからです。
ファイルに対して UNIX 形式の属性ビットを操作するときは、ライブラリは Win32 API では提供されていない幾つかの情報を埋めなければなりません。
ファイル名が .exe 及び .bat であれば実行可能と判断しますし、またファイルの先頭が「#!」であるものも同様です。
Cygwin はマルチユーザ環境では安全ではありません。 例えば、普通のユーザがログインするような環境で「inetd」のようなデーモンを Administrator 権限でずっと走らせたり、 あるいは誰かがコンソールからログインしている間に他のユーザがリモートからログインしたりすると、ある種の Cygwin クライアントは他のクライアントをだましてコードを実行させることができます。 この方法によってあるユーザは、そのマシンで動作している他の Cygwin プログラムの権限を得ることができてしまいます。 全てのプロセスからアクセス可能な共有状態を Cygwin が持っているからです。
(Tim Newsham (newsham@lava.net) 氏から説明を頂きました。 ありがとうございます。)
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Cygwin におけるネットワークのサポートは、WinSock API ではなく UNIX API の提供を想定しています。
API 上は同じ名前の関数でも、意味の違う関数が存在します。
例えば、UNIX の select システムコールは標準ファイルハンドル及びソケットのハンドルに対して待つことができますが、 WinSock の select コールはソケットのみです。 このため、cygwin.dll はさまざまな WinSock/Win32 関数に、無理矢理 UNIX select と同じようなことをさせるために、裏ではかなり汚い手を使っています。
もし既に WinSock を使っているアプリケーションを移植しようとしているのであれば、 Cygwin のネットワークサポートを使用するのは間違っています。
しかし、Cygwin ではネイティブの WinSock も使用可能です。 cygwin.dll が export している関数は「cygwin_<name>」という名前です。 数多くのマクロ定義によって、標準の UNIX での名前から DLL で export されている名前への関連付けが行われています。include/netdb.h を覗いてみてください。
..(中略).. void cygwin_setprotoent (int); void cygwin_setservent (int); void cygwin_setrpcent (int); ..(中略).. #ifndef __INSIDE_CYGWIN_NET__ #define endprotoent cygwin_endprotoent #define endservent cygwin_endservent #define endrpcent cygwin_endrpcent ..(中略)..
標準 UNIX ヘッダファイルをインクルードすれば、UNIX → Cygwin のマッピングが行われる、というアイデアです。 これを使った場合、libwinsock.a をリンクする必要はありません。 ネットワークに必要な全てのものは DLL 内にあります。
mywinsock.h ファイルは標準の winsock.h をハックしたもので、標準の UNIX API と衝突するビット値や他のヘッダで定義されているものを削除したものです。 例えば、mywinsock.h においては struct hostent の定義は削除されています。 UNIX マシンでは、この定義は netdb の中にあるからです。 これをあなたのアプリケーションで使うのはよくありません。
b19 リリースでは、この情報はやや古くなっています。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
そのままの Win32 WinSock を使うために必要なのは、ソースファイルの先頭に #define
Win32_Winsock と #include "windows.h"
を記述することだけです。 また、libwsock32.a をリンクするために、 コンパイラのコマンドラインに
-lwsock32 を追加する必要があるでしょう。
共有ライブラリの状態に依存するため、Cygwin のバージョン付けは比較的分かりにくいものとなっています。 まず最初に、1998
年 10 月以降の全ての Cywgin DLL は cygwin1.dll と命名されています。ここで、1
はリリース名です。 加えて、DLL にはリリース名に対応したメジャー番号及びマイナー番号があります。
つまり、cygwin-1.5.10-2 はメジャー番号 5、マイナー番号 10、リリース 2 の
cygwin1.dll ということです。
cygwin1.dll
のメジャー番号は、既存のソフトウェアに対する非互換性が発生した場合にのみ上がります。 例えば、メジャーバージョン 5
の最初のリリースである cygwin-1.5.0-1 では、64 ビットファイル I/O
操作が加えられました。これによって、多くのライブラリで再コンパイル及び再リンクが必要となりました。 マイナー番号の変更では、常に
Cygwin のリリースで後方互換性が維持されています。cygwin1.dll
のリリースバージョン番号もありますが、リリース番号は既存のリリースに対して、DLL
に対して何ら影響を及ぼさない変更(ヘッダファイルが不足していた、など)が加わった場合にのみ上がります。
Cygwin API のメジャー番号、及びマイナー番号もあります。このメジャー番号は、API の後方互換性を失わせるような重大な変更が行なわれるにつれて変化します。 以前のメジャー番号の DLL とリンクされた実行ファイルは、最新の DLL との互換性はなくなるでしょう。 マイナー番号は、意味のある API の追加や変更に対して変化します。 これは古い実行ファイルを壊すことはしませんが、再コンパイルしたものが必要になることがあります。
そして、共有メモリ領域の互換性バージョン番号があります。
これは共有メモリ領域やその他の名前付き共有ミューテックス、セマフォなどに対して互換性を失わせるような変更が行われたときに上げられます。
最後に、レジストリ内のマウントテーブルのレイアウトに対して後方互換性のない変更が加えられた場合に変更されるマウントポイントレジストリバージョン番号があります。
これは長い間、mounts v2 となっています。 Cygwin
のバージョン番号に関する更なる詳細については、ファイル
/usr/include/cygwin/version.h を参照して下さい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
_timezone の値を参照する前に tzset() を明示的に呼び出していますか? そうでなければ、これを呼び出しておかなくてはなりません。
Cygwin からマウスイベントを取得する方法はありません。 このサポートを追加する計画は今のところありません。
パッケージのメンテナになるつもりでしょうか。素晴らしいことです。Cygwin チームの最重要目的は Cygwin それ自身であるので、我々はパッケージを準備しメンテナンスするボランティアを早急に必要としています。
パッケージメンテナとなるために知っておかなければならないことについての詳細は http://cygwin.com/setup.html にある Cygwin Package Contributor's Guide に全て記述されています。 パッケージのメンテナンスに関する質問があれば、cygwin-apps メーリングリスト( http://cygwin.com/lists.html から始めて下さい)が利用出来ます。勿論、cygwin-apps メーリングリストのアーカイブを調べた後にですよ。 Charles Wilson 氏は texinfo を例にとって、何を含むべきかについての短いレシピを投稿しました。このレシピは http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html で参照することが出来ます (11)。 何が必要かについてのアイデアを与えてくれることでしょう。
他の人が同じ事を考えているといけないので、その意図を一般の Cygwin メーリングリストに対して発表すべきです。
Cygwin それ自身に対して何かを寄贈したいのであれば、 http://cygwin.com/contrib.html を参照して下さい。
デフォルトでは、gcc は全シンボルを含んでコンパイルします。UNIX でも gcc は巨大な実行形式を作成します。
もしそれが邪魔であれば、binutils パッケージ中に含まれる「strip」プログラムを使うだけです。又は gcc に `-s' オプションを与えてコンパイルします。
Cygwin は glibc を提供しません。代わりに、同じ機能の大部分(全てではありません)を提供する newlib を使用します。 glibc を Cygwin へ移植するのは難しいでしょう。
Objective C は gcc の Cygwin 版は含まれておらず、また含まれる予定もありません (12) 。 gcc パッケージのメンテナはそれをビルドするのに苦労していましたし、 しかもビルド出来たとしてもそれには問題が残っていました。 とにかく、メインの GCC ディストリビューションに含まれる Objective C フロントエンドには最低限のサポートしか含まれていないように思えるのです。
まず最初に、`make -j[N]' を使用しているのであれば make は止まります。 それは正しく動作しません。
そうでなければ、読み続けて下さい...
make は UNIX と WIN32 という二つの処理モードを持っています。 正しいモードで処理していることを確かめる必要があります。
UNIX モードでは、make はサブシェルとして sh.exe を使用します。 パスのリストは「:(コロン)」、エスケープキャラクタは「\」となり、 POSIX パスが使われ、Cygwin のマウントが解釈されます。 UNIX 用に書かれた Makefile を扱うときはこのモードを使用します。
WIN32 モードでは、make は「ネイティブ」のコマンドシェル (cmd.exe 又は command.com)を、 そのコマンドシェルが持つ全ての制限と共に使用します。 パスのリストは「;(セミコロン)」で区切られ、 パスの区切りは「\」です。「copy」と「del」が使用できますが、 Cygwin のマウントテーブルは利用できません。 nmake (13) スタイルの Makefile を扱うときはこのモードを使用します。
ネットリリース版の make(setup.exe でインストールされるもの) のデフォルトのモードは
UNIX です。 Redhat(以前は Cygnus)の顧客に対する製品版リリースでは WIN32 です。
デフォルト値は環境変数 MAKE_MODE を 「UNIX」(実際には大文字小文字の区別はありません) 又は「WIN32」(実際には「UNIX」以外) と設定することによって上書き出来ます。 make のコマンドラインオプション --unix 又は --win32 によっても指定できます。
ソースの中に空の main() 関数を追加してみてください。
又は、リンクのコマンドライン中で `-lm' をかなり前のほうにおいているのでしょう。 それは最後に置かれなければなりません。
bash$ gcc hello.c -lm bash$ ./a.exe Hello World!
は動作しますが、しかし次の場合は動作しません。
bash$ gcc -lm hello.c /c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main' /usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here /usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@16' collect2: ld returned 1 exit status
libm.a は作り物で、libcygwin.a へのシンボリックリンクです。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
非常に簡単です。Cygwin ツールが必要とするのは、使おうとする Win32 API 関数のインポートライブラリを明示的にリンクすることだけです。 例外は kernel32 で、これは自動的にリンクされます(スタートアップや組込みのコードがそれを使うからです)。
例えば、グラフィック関数(GDI)を使う場合は gdi32 を次のようにリンクしなければなりません。
gcc -o foo.exe foo.o bar.o -lgdi32
或いは(コンパイルとリンクを一ステップで行うなら)、
gcc -o foo.exe foo.c bar.c -lgdi32
とします。以下のライブラリがこの方法で利用可能です。
advapi32 largeint ole32 scrnsave vfw32 cap lz32 oleaut32 shell32 win32spl comctl32 mapi32 oledlg snmp winmm comdlg32 mfcuia32 olepro32 svrapi winserve ctl3d32 mgmtapi opengl32 tapi32 winspool dlcapi mpr penwin32 th32 winstrm gdi32 msacm32 pkpd32 thunk32 wow32 glaux nddeapi rasapi32 url wsock32 glu32 netapi32 rpcdce4 user32 wst icmp odbc32 rpcndr uuid imm32 odbccp32 rpcns4 vdmdbg kernel32 oldnames rpcrt4 version
通常のセットアップでは、-mwindows オプションをコマンドラインに与えることで user32、gdi32、IIRC、comdlg32 などを含む基本的なライブラリ群を含めることが出来ます(そしてプログラムはコンソールプログラムではなく、GUI プログラムになります)。
但し、ld を直接起動しているのでない限り -lkernel32 をリンク行に含めてはいけないことに注意してください。 リンク行に同じインポートライブラリを二度含めてはいけません。 最後に、インポートライブラリはリンク行の最後か、少なくともそれを参照する全てのオブジェクトファイル、スタティックライブラリの後ろに置くのが良い方法です。
最初の 2 つは、インポートライブラリが二度参照される際に発生するリンカの問題に関連しています(少なくとも b18 以降)。 テーブルが破壊され、プログラムが無作為にクラッシュしてしまいます (14)。 最後の点は、gcc がコマンドライン上のファイルのリストを順番に処理し、ライブラリを参照しているファイルの後ろにあるライブラリに対してのみ参照の解決を行うという事実に関係しています。
gcc の -mno-cygwin フラグによって、gcc は Cygwin の代わりに標準の Microsoft DLL をリンクするようになります。 これは UNIX エミュレーション層を必要としないネイティブ Windows プログラムのためのものです。
これは完全に別個の試みである「MinGW」(Minimalist GNU for Windows) とは混同されません。このプロジェクトのホームページは http://www.mingw.org/index.shtml です。
いいえ。プログラムが Cygwin API を利用するのであれば、その実行形式は cygwin1.dll なしには実行出来ません。 特に、ライブラリから独立しライブラリを自分自身に包含した形の実行形式を作成すべく、Cygwin ライブラリを静的リンクすることは不可能です。
あなたの Cygwin アプリケーションを配布する際にこれが問題となるのであれば、ライセンスオプションについて記述された http://cygwin.com/licensing.html を読み、理解することをお薦めします。 Red Hat から特別な商用ライセンスを購入しない限り、あなたの Cygwin アプリケーションは必然的にオープンソースとなります。
いいえ、どちらか一つだけを使用しなければなりません。それらは相互に排他的なものです。
コンパイル時のデフォルトは、コンソールアプリケーションを生成するようになっています。 GUI プログラムを書いているのであれば、先に説明したように -mwindows オプションをつけてコンパイルするか、「-Wl,--subsystem,windows」を gcc のコマンドラインに追加して下さい。
通常、この問題はテキストエディタで Makefile のタブをスペースで置き換えた結果として発生します。 コマンド行はタブで始まらなくてはなりません。これは Cygwin に限った話ではありません。
「Microsoft Open Tools License agreement」のサブセクション 2.d.f には、「エンドユーザに対して再配布可能な形で更に再配布することは認められない」とあるようです。 我々はこれを、「我々はこれらをあなたに提供することは出来るが、あなたは他の誰かにこれらを提供することは出来ない」という意味であると理解しました。 これは Red Hat としては賛成出来ないことです。しかしながら幸運にも、我々はほぼ完璧な独自の Win32 ヘッダを持っています。
私の知っている限り、Cygwin の開発者でそのようなことをした人間はいません。 しかしメーリングリストでの報告によれば、次のようにすれば出来るようです。
impdef cygwin1.dll > cygwin1.def
lib /def=cygwin1.def /out=cygwin1.lib
#include <sys/cygwin.h>
#include <stdlib.h>
typedef int (*MainFunc) (int argc, char *argv[], char **env);
void
my_crt0 (MainFunc f)
{
cygwin_crt0(f);
}
他の Cygwin を利用するライブラリを利用する場合は、gcc を利用してそれらのライブラリを DLL としてビルドし、Microsoft Visual C リンカ用のインポートライブラリを作成する必要があるでしょう。
この情報を提供してくれた Alastair Growcott (alastair dot growcott at bakbone dot co dot uk) 氏に感謝します。
`.lib' ファイルが通常の静的な、或いは C から呼び出し可能なエントリポイントを持つインポートライブラリであれば、`foo.lib' を `*.o' のような gcc/g++ のオブジェクトファイルとして利用することが出来ます。 そうでなければ、以下の作業を行って下さい。
この方法で、Microsoft Visual C(とその他多くのランタイムライブラリ)を Cygwin 開発ツールから使うことができます。 これは大変な作業(丸半日かその程度かかるでしょう)ですが、それでも問題のランタイムライブラリを仕様から書き直すよりはまだましでしょう…。 (Jacob Navia (root at jacob dot remcomp dot fr) 氏から説明をいただきました。ありがとうございます。)
必要となる全てのコンポーネントを単一のディレクトリ(我々は /src を利用しています)に展開します。 理想的には、必要となるものを CVS (http://cygwin.com/cvs.html)からチェックアウトすべきです。 それは、ソースを手に入れるために 推奨されている方法 です。 そうでなければ Cygwin ディストリビューションから適切なソースパッケージを取得して展開することも可能です。
これを書いている時点では、少なくとも Cygwin のソースパッケージと w32api のソースパッケージを展開する必要があります。 winsup ソースパッケージは最初に展開されるべきであり、w32api ソースディレクトリは winsup ソースパッケージ展開後に作成される「winsup」ディレクトリの中で展開されなければなりません。 そして、w32api-<バージョン番号> を w32api へとリネームします。
パッケージのリリースは常にロックステップ(lock step)にあるわけではないので、Cygwin ソースパッケージは w32api パッケージのより新しいバージョンを必要とするかもしれません(CVS を利用する、もう一つの理由です)。
Cygwin はソースとは別のディレクトリでビルドする必要があります。 /obj ディレクトリのようなディレクトリを作成して下さい。そのディレクトリでビルドを実行することになります。
bash cd /obj /src/configure --prefix=/install -v > configure.log 2>&1 make > make.log 2>&1 make install > install.log 2>&1
通常、この手順ではドキュメントのビルド時に発生するエラーは無視されます。 ドキュメントのビルドには Cygwin ディストリビューションには含まれていないツールが必要です。 Linux 上でドキュメントのビルドを行いたければ、大部分のディストリビューションで docbook-utils として提供されているパッケージに、必要となる全てが含まれています。 ドキュメントのビルドに関する更なる情報については、cygwin-doc パッケージに含まれている README ファイルを参照して下さい。
cygwin1.dll のチェックを行うためには、winsup/cygwin ディレクトリで「make check」を実行します。 これが動作したなら、(可能であれば)DLL を除く全てをインストールします。 続いて、全ての Cygwin プログラム(bash、inetd などを含む)を終了させ、古い DLL を保存し、新しい DLL を正しい場所にコピーします。そうしたら bash、或いは他の Cygwin プログラムを Windows のコマンドプロンプトから実行し、何が起こるのかを見てみましょう。
「shared region is corrupted(共有領域が汚染されている)」というエラーが出た場合、二つのバージョンが異なる cygwin1.dll が同時にマシン上で動作していることを意味しています。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
残念ながら、これは難しいです。 Microsoft が PowerPC 版 NT の開発を打ち切って以来(1996 年後半)、ずっとビルドされていません。 例外処理やシグナルサポートのセマンティックス、引数が x86 版では修正されていますが、PPC 用には更新されていません。 従って、PPC 特有のサポートを書き直す必要があるでしょう。 他にどのような非互換性があるかわかっていません。もしこれを修正して下さるなら、ぜひ我々にパッチを送ってください!
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Alpha 版 NT 用には移植されておらず、現時点では移植する予定もありません。 Alpha 版 NT をサポートする修正をどなたか寄贈していただけると嬉しいです (15)。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
gcc にヒープ・スタックサイズのリンクオプションを渡して下さい。 foo.exe をヒープサイズ 1024、スタックサイズ 4096 で作成するには、 gcc をこのように起動して下さい。
gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c
`objdump -p' がこの情報を提供しますが、少し冗長です。
`cygcheck' はより簡潔であり、パスに含まれるコマンドを再帰的に処理します。
cygcheck には現在、Windows システムディレクトリ(C:\WINDOWS や C:\WINNT など)にあるプログラムは、仮にパスに含まれていても報告されないというバグがあることに気をつけて下さい。 このバグに対処するには、実行形式への完全な Win32 パスを .exe 拡張子を含めて指示します。
cygcheck c:\\winnt\\system32\\cmd.exe
(bash 上でタイプする場合、Windows パスの区切り文字はエスケープされねばならないことに気をつけて下さい。)
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Cygwin プロジェクトのメインの Web ページ( http://cygwin.com/ )に、この手順について説明したドキュメントがあります (16)。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
gdb で *0x401000 にブレークポイントを設定し、当該プログラムを実行して下さい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。 しかし、この問題に関する議論が最近 Cygwin メーリングリストで行われました。 http://cygwin.com/ml/cygwin/2000-06/msg00688.html 及び関連するメッセージを読んで下さい。)
以下に示す 5 つのコマンドを、この順序で実行しなければなりません。
$(LD) -s --base-file BASEFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) -s --base-file BASEFILE EXPFILE -dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) EXPFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
この例では、 $(LD) はリンカ ld です。
$(DLLTOOL) は dlltool です。
$(AS) はアセンブラ as です。
DLLNAME はあなたが作ろうとしている DLL の名前、例えば tcl80.dll などです。
OBJS は DLL に入れようとしているオブジェクトファイルのリストです。
LIBS はその DLL にリンクしたいライブラリのリストです。 例えば -lcygwin は必要かもしれませんし、不要かもしれません。 -lkernel32 は必要でしょう。Tcl は -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lkernel32 をリンクします。
DEFFILE はあなたの定義ファイルです。 単純な DEFFILE は「EXPORTS」と、それに続く DLL が公開する全てのシンボル名のリストからなります。各シンボルは一つで一行でなくてはなりません。 他のプログラムは、ここでリストされたシンボルにのみアクセス出来るようになります。
BASEFILE はこの 5 段階の処理中に使われる一時ファイル、例えば tcl.bash などです。
EXPFILE はまた別の一時ファイル、例えば tcl.exp などです。
ENTRY はエントリポイントとして使用する関数の名前です。 この関数は WINAPI 属性付きで 3つの引数を取らなくてはなりません:
int WINAPI startup (HINSTANCE, DWORD, LPVOID)
実際のシンボル名には @12 が付加されるので、本当のエントリポイントの名前が `startup' であれば、ENTRY に指定する文字列はこの例では `startup@12' ということになります。
もしあなたの DLL が Cygwin API の関数を呼び出すのであれば、エントリ関数は Cygwin「不純(impure)」ポインタを初期化する必要があります。これはグローバル変数 `_impure_ptr' を宣言し、エントリ関数中で初期化することによって行います。 このグローバル変数 `_impure_ptr' は DLL から公開しないように注意して下さい。つまり、DELFILE には入れないで下さい。
/* これは大域変数です。 */
struct _reent *_impure_ptr;
extern struct _reent *__imp_reent_data;
int entry (HINSTANT hinst, DWORD reason, LPVOID reserved)
{
_impure_ptr = __imp_reent_data;
/* Whatever else you want to do. */
}
$(LD) 行には「--subsystem windows」オプションを付け加えても構いません。 Tcl のビルドではそうしていますが、これが重要だったかどうかはもはや覚えていない、ということを白状しておきます。 ld に --subsytem <x> フラグを指定する場合、-e エントリは sybsystem フラグの後に来なければならないことに注意してください。 というのは、subsystem フラグは異なったデフォルトのエントリポイントを設定するからです。
$(LD) 行には「--image-base BASEADDR」オプションを付け加えても構いません。 これはデフォルトのイメージベースを設定します。この DLL を使用するプログラムは、個々の DLL がアドレス空間の別々の場所を占有すると、 起動が少しだけ早くなります。個々の DLL は、このイメージベースから始まって必要なサイズだけを連続して占有します。
さて、これであなたの DLL が出来たので、他のプログラムからリンクできるようにライブラリを作りたくなるでしょう。 これは必須ではありません。LoadLibrary によって常にその DLL を使うことが出来るからです。しかしながら、DLLを直接リンクできるようにしたければ、ライブラリを作成する必要があります。 このようにして下さい。
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE --output-lib LIBFILE
$(DLLTOOL)、$(AS)、DLLNAME、DEFFILE は上記と同じです。 DLLNAME と DEFFILE は必ず同じものを使って下さい。そうでなければ正しく動作しません。
LIBFILE は作成しようとするライブラリの名称、例えば libtcl80.a などです。 これでリンカコマンドに -ltcl80 などと指定することによって、このライブラリをリンク出来ます。
gdb を使ってアプリケーションをデバッグすることができます。 -g
フラグと共にコンパイルするのを忘れないで下さい! そのアプリケーションが MS の DLL にある関数
を呼び出しているのであれば、gdb はプログラムの実行時に、これらの DLL
のデバッグ情報をロードできないと文句を言ってくるでしょう。 これは正常です。何故なら、これらの DLL
はデバッグ情報を持っていないからです(仮に持っていたとしても、そのデバッグ情報には gdb との互換性はないでしょう)。
はい。様々なデバッグ及びトレースメッセージを利用可能にして他の Cygwin
プログラムを実行させるために、strace.exe ユーティリティを使用することが出来ます。
strace の使用方法に関する情報については、Cygwin ユーザーズガイド又は
winsup/utils/utils.sgml ファイルを参照して下さい。
不幸なことに、現在の gdb には最小限のシグナルハンドリングしか実装されていません。 シグナルハンドリングは Windows タイプのシグナルに対してのみ動作します。 SIGINT、SIGFPE に対しては動作し、無論 SIGSEGV に対しても動作します。 デバッグ中のプロセスに対する SIGUSR1 又は SIGHUP のような「stop」「print」又は「nopass」シグナルは扱えません。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
よくあるエラーとしては、コマンドライン上で、ライブラリを必要とするものよりも前にそのライブラリを置いてしまう、というものがあります。
誤: gcc -lstdc++ hello.cc.
正: gcc hello.cc -lstdc++.
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
その関数は恐らくヘッダファイルで宣言されていないか、あるいは Unicode 用のものが入っていないかでしょう。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
はい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
malloc.h の代わりに、stdlib.h をインクルードして下さい。
もしあなたのプログラム中で malloc という名前の関数を定義して DLL(cygwin1.dll)
(17)
をリンクした場合、 DLL はあなたの malloc を呼び出します。
言うまでもないことですが、もしあなたの malloc にバグがあるようなら深刻な問題に陥るはめになるでしょう。
プログラムを bash からではなく DOS コマンドプロンプトから実行した場合、DLL
はコマンドラインのワイルドカードを展開しようとします。 この処理は main 関数の処理が開始される前に
malloc を呼び出します。もしあなたの malloc
が、main
が呼び出された後に発生する初期化を必要とするように記述されている場合、間違いなく問題が起こるでしょう。
更に、newlib には _malloc_r
に関する未解決の問題があります。 この malloc の再入可能バージョンはあなたが作成した
malloc をバイパスして newlib 内部で直接呼び出され、自作の
malloc とは両立しないことでしょう。 しかし、_malloc_r
をも置き換えるということは恐らく出来ません。 なぜなら cygwin1.dll は
_malloc_r をエクスポートしておらず、しかも Cygwin はあなたのプログラムが
_malloc_r を置き換えているということは想定していないからです。 これは newlib
の問題ですが、我々はこの問題をどうするかということに対する提案は受け付けています。
はい、C のオブジェクトファイルを扱っている限りは動作するはずです。 Microsoft Visual C++ は GNU C++ とは異なった方法で名前の変形を行なうため、C++ オブジェクトを混在させるのは困難でしょう。
いいえ、完全な(高級言語レベルでの)デバッグはできません。 Microsoft のコンパイラは gdb が理解出来ない異なったタイプのデバッグ用シンボル情報を生成します。
しかし、Microsoft のコンパイラが生成する低レベル(アセンブラ型)のシンボルは coff であり、これは gdb が理解「出来ます」。 従って、少なくとも全てのグローバルシンボルは見ることが出来るはずですが、データ型、行番号、ローカル変数などの情報は得られません。
Intel の現在のチップの CPU リファレンスマニュアルは、Intel の Web サイト( http://developer.intel.com/design/pro/manuals/ )から PDF 形式でダウンロード出来ます。
スクリプトがカレントディレクトリにある場合、$PATH の中に `.'(ドット)が必要です(通常、これはデフォルトではありません)。 Makefile から起動される全てのシェルスクリプトの前に、個々に /bin/sh を付け加える必要はありません。
Win32 API へアクセスすることを示すには _WIN32 を、DLL が提供する Cygwin 環境にアクセスすることを示すには __CYGWIN__ を使用します。
_WIN32 を選んだのは Microsoft が VC++ の中で定義しているものであり、VC++ のサンプルに従えるよう互換性を保持するのは良いことであると考えたからです。 我々は _MFC_VER を使用して、VC++ でコンパイルされるべきコードを指示しています。
_WIN32 は gcc コマンドラインオプションで、 -mno-cygwin 或いは -mwin32 のどちらかを指定したときのみ定義されます。 これは、Cygwin が UNIX のエミュレーション環境をサポートしているからであり、また Windows 環境上での特別な利権(これらは、Cygwin が自動的に取り扱います)を必要とすると考えられる、幾つかのプログラムを混乱させないようにするためです。
-mno-cygwin を利用すると、利用するコンパイラ(或いは設定)に __CYGWIN__ ではなく __MINGW32__ を有効にするよう伝えることになることに注意して下さい。 例えば、以下を実行すれば何が起こるか分かるでしょう。
$ gcc -dM -E -xc /dev/null >gcc.txt $ gcc -mno-cygwin -dM -E -xc /dev/null >gcc-mno-cygwin.txt $ gcc -mwin32 -dM -E -xc /dev/null >gcc-mwin32.txt
何か異なっているかを調べるには、diff 及び grep ユーティリティを使って下さい。
UNIX 上の GUI を Windows に移植するには、基本的に二つの戦略があります。
第一の方法は、Tcl/Tk、X11、V(その他にも?)など、移植性のあるグラフィクスライブラリを使用することです。 普通は、何らかのランタイムサポートを必要とする Windows 上の GUI が出来るでしょう。 Tcl/Tk の場合、それに必要なライブラリファイルと Tcl/Tk DLL を含めることになるでしょう。 X11 の場合、そのプログラムを使う人全員に、X11 サーバをインストールしてもらう必要があるでしょう。
第二の方法は、その GUI を Win32 API 呼び出し(あるいは VC++ の MFC)で書き直してしまう方法です。 プログラムが非常にモジュール化されて書かれており、共通部分の(GUI に関連しない)コードが多く含まれているのであれば、Cygwin を使い続けることが出来ます。 この方法であれば、Cygwin の利用による移植上の優位性を保つことが出来ます。
DJGPP は同様のアイデアですが、それは Win32 用ではなく DOS 用のものです。 DJGPP はアプリケーションに対して適切な操作インタフェースを提供するために「DOS エクステンダ」を使用しています。 Cygwin ツールセットでは全てのアプリケーションがネイティブ Win32 なので、その必要はありません。 Cygwin ツールでコンパイルされたアプリケーションは全ての Win32 API 関数にアクセスできるので、Windows の GUI を使ったプログラムを書くことも出来るのです。
DJGPP に関する詳しい情報は http://www.delorie.com/ から得ることが出来ます。
Go to the first, previous, next, last section, table of contents.