ファイル記述子リンクの移植性

私は今、そうやるので、私はいつも、これを疑問に思いませんが、決して見つけるために時間がかかってきました-使用法がどのようにポータブルここに示したいずれかの/proc/$$/fd/$Nか/dev/fd/$N？私はPOSIXの保証 を理解して/dev/null, /dev/tty, and /dev/console います（この回答に関するコメントを読んだ後、先日それを見つけただけです）が、これらの他のものはどうですか？

私が知る限り、それらはかなり一般的ですが、どのシステムでそれらを見つけることは期待できませんか？何故なの？どちらか一方を見つける可能性が高いですか？彼らはいつも同じような属性を示しますか？

私はこれらのデバイスをあらゆる方法でかなり広範囲に使用する傾向があるので、試してみるだけで不足する可能性があるかどうかを知りたいです。

また、上記の質問は私が知りたいと思うものだけであると理解されるべきですが、私は明らかに最初に尋ねなければならないので、私はこの点で最もよく知らないかもしれず、それらは厳しい要件と見なされるべきではありません答え。可能であれば手掛かりをお願いします。

シンボリックリンクは、Linux上で準普遍的ですが、彼らは（それらをエミュレートするCygwinの上を除く）どこにも存在しません。AIXおよびSolarisにも存在しますが、シンボリックリンクではありません。移植性があるため、開いているファイルに関する情報を取得するには、をインストールします。/proc/PID/fd/NUM/proc/PID/fd/NUMlsof

ユニックス /proc/PID/fd

Linux

Linuxでは、IDがPIDのプロセスがファイル記述子NUMで開いているファイルへのわずかに魔法のシンボリックリンクです。このリンクは、たとえば、ファイルが削除されてもファイルへのアクセスに使用できるという点で魔法です。リンクも名前の変更によりファイルを追跡します。PIDがリンクにアクセスするプロセスである場所を指す魔法のシンボリックリンクです。/proc/PID/fd/NUM/proc/self/proc/PID

この機能は、事実上すべてのLinuxシステムに存在します。proc filesystemのドライバーによって提供されます。これは技術的にはオプションですが、組み込みシステムでもほとんど除外されないほど多くのこと（ps作業の作成を含む-から読み取る）に使用されます。/proc/PID

シグウィン

Cygwinは、Linux （Cygwinプロセス用）およびをエミュレートします。/proc/PID/fd/NUM/proc/self

Solaris（バージョン2.6以降）、AIX

各ファイル記述子にはエントリがありますが、開いているファイルと同じタイプとして表示されるため、ファイルのパスに関する情報は提供されません。ただし、ファイルを開いているプロセスに報告するのと同じ情報を報告するため、ファイルが配置されているファイルシステムとそのiノード番号を判別できます。ディレクトリはシンボリックリンクとして表示されますが、それらは追跡可能な魔法のシンボリックリンクであり、空の文字列を返します。/proc/PID/fdstatfstatreadlink

AIXでは、procfilesコマンドはプロセスの開いているファイルに関する情報を表示します。Solarisでは、pfilesコマンドはプロセスの開いているファイルに関する情報を表示します。これには、ファイルへのパスは含まれません（Solarisでは、Solaris 10以降に含まれます。以下を参照）。

Solaris（バージョン10以降）

に加えて、最新のSolarisバージョンには、のLinuxのシンボリックリンクに類似したシンボリックリンクが含まれています。このコマンドは、パスなど、プロセスの開いているファイルに関する情報を表示します。/proc/PID/fd/NUM/proc/PID/path/NUM/proc/PID/fd/NUMpfiles

Plan9

/proc/PID/fdプロセスによって開かれたファイル記述子ごとに1つのレコード（行）を含むテキストファイルです。ファイル名はそこで追跡されません。

QNX

/proc/PID/ はディレクトリですが、ファイル記述子に関する情報は含まれていません。

/procファイル記述子への直接アクセスはあるが直接アクセスしないユニックス

（注：場合によっては、アクセス可能なメモリイメージを参照することにより、プロセスの開いているファイルに関する情報を取得できることがあります/proc。これを「直接アクセス」とは見なしません。）

ファイルがどこにあるか/proc/PID

procファイルシステム自体はUNIX 8thエディションで始まりましたが、構造は異なり、プラン9を経ていくつかの大学に戻りました。を持つすべてのオペレーティングシステムには/proc各PIDのエントリがあると思いますが、多くのシステムでは、ディレクトリではなく通常のファイルです。次のシステムにはを読む必要があるがあります：/proc/PIDioctl

• Solaris 2.5まで
• OSF / 1は現在Tru64として知られています
• IRIX（？）
• SCO（？）

ミニックス3

MINIX 3には、ディレクトリを含むいくつかのLinuxに似たコンポーネントを提供するprocfsサーバーがあります。ただし、これはありません。/proc/PID//proc/PID/fd

FreeBSD

FreeBSDにはディレクトリがありますが、オープンファイル記述子に関する情報は提供しません。（ただし、Linuxに似ており、シンボリックリンクを介して実行可能ファイルにアクセスできます。）/proc/PID//proc/PID/file/proc/PID/exe

FreeBSDのprocfsは非推奨です。

ユニックスなし /proc

• HP-UX
• OpenBSD
• NetBSD
• Mac OS X

他のチャネルを介したファイル記述子情報

定着器

このfuserコマンドは、指定したファイルが開いているプロセス、または指定したマウントポイントで開いているファイルをリストします。このコマンドは標準です（すべてのXSI準拠システム、つまりX / Open System Interface Extensionを備えたPOSIXで使用可能）。

このユーティリティを使用してプロセスからファイル名に移動することはできません。

LSOF

Lsofは「開いているファイルをリストする」の略です。これは、ほとんどのUNIXバリアントで使用可能なサードパーティ製ツールです（通常、デフォルトのインストールの一部ではありません）。開いているファイルに関する情報の取得は、上記の分析により疑わしい可能性があるため、システムに非常に依存しています。lsofメンテナーは、すべてを単一のインターフェースの下で結合する作業を行いました。

FAQを読んで、lsofがどのような困難に耐えなければならないかを確認できます。ほとんどの場合、開いているファイルの名前に関する情報を取得するには、カーネルデータ構造を解析する必要があります。FAQ 3.3「なぜlsofはフルパス名を報告しないのですか？」

Lsofは、次の方言のカーネル名キャッシュからパス名コンポーネントを取得できません。

• AIX

Linuxカーネルのみが、開いているファイルについて保持する構造にフルパス名を記録します。代わりに、ほとんどのカーネルはパス名をデバイスとノード番号のダブレットに変換し、ファイルを開いた後のファイル参照にそれらを使用します。

lsofの出力から情報を解析する必要がある場合は、-Fモード（1行につき1フィールド）、できれば-F0モード（ヌル区切りフィールド）を使用してください。特定のプロセスの特定のファイルディスクリプタについての情報を取得するには、使用-aしてオプションと例えば、。-p PID-d NUMlsof -a -p 123 -d 0 -F0n

/dev/fd/NUM 現在のプロセスのファイル記述子用

多くのUNIXバリアントは、プロセスがファイル名を介して開いているファイルにアクセスする方法を提供します。opening はを呼び出すことと同等です。これらの名前は、プログラムがファイル名を必要としているが、すでに開いているファイル（パイプやソケットなど）を渡したい場合に役立ちます。たとえば、プロセス置換を実装するシェルは、使用可能な場合は使用します（使用できない一時的な名前付きパイプを使用します）。/dev/fd/NUMdup(NUM)/dev/fd

/dev/fd存在する場所には、通常（常に？）の同義語もあります（シンボリックリンク、時にはハードリンク、時には同等のプロパティを持つマジックファイル）/dev/stdin= /dev/fd/0、/dev/stdout= /dev/fd/1、/dev/stderr= /dev/fd/2。

• Linuxでは、/dev/fdへのシンボリックリンク/proc/self/fdです。
• ほとんどの大学（IRIX、OpenBSD、NetBSD、SCO、Solarisなど）では、のエントリ/dev/fdはキャラクターデバイスです。通常、ファイル記述子が開いているかどうかに関係なく表示され、特定の数を超えるファイル記述子のエントリは利用できない場合があります。
• FreeBSDおよびOSXでは、fdescfsファイルシステムは/dev/fd、呼び出しプロセスのオープン記述子に従う動的ディレクトリを提供します。/dev/fd使用可能な静電気は/dev/fdマウントされていません。
• OSF / 1（Tru64）では、fdfs/dev/fdを介して提供されます。
• /dev/fdAIXまたはHP-UXにはありません。

この方法/procは実装されており、提供される機能は標準化されていません。たとえば、こちらを参照してください。ウィキペディアによると、FreeBSDは「段階的に廃止」されています。詳細/procはこちらをご覧ください。

の時点で/dev、/dev/fd/POSIXまたはシングルユーザー仕様（SUSv3）の一部ではありませんが、System VおよびBSDはそれをサポートしています。

補遺：

Linux：/dev/fd/*へのシンボリックリンク/proc/self/fdです。

FreeBSD：/dev/fd/*fdescfsを通じて提供されます。

NetBSD：FreeBSDと同じ。

OpenBSD：FreeBSDと同じです。

Solaris：があり/dev/fd/*ます。

IRIX：があり/dev/fd/*ます。

Tru64 Unix：nixdoc.netに/dev/fd/*よると、HPの本物のTru64ドキュメントはわかりにくい（少年、なんてこった！何も見つけられない！）。

AIX：公的に入手可能なドキュメントからは兆候は見つかりませんでした。

HP-UX：AIXと同じ。