Это - inode число для канала или рассматриваемого сокета.
Канал является однонаправленным каналом с концом записи и концом чтения. В Вашем примере похоже, что FD 5 и FD 6 говорят друг с другом, так как inode числа являются тем же. (Возможно, не, все же. Посмотрите ниже.)
Более распространенный, чем наблюдение программы, говорящей с собой по каналу, пара отдельных программ, говорящих друг с другом, обычно потому что Вы настраиваете канал между ними с оболочкой:
shell-1$ ls -lR / | less
Затем в другом окне терминала:
shell-2$ ...find the ls and less PIDs with ps; say 4242 and 4243 for this example...
shell-2$ ls -l /proc/4242/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 1 -> pipe:[222536390]
shell-2$ ls -l /proc/4243/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 0 -> pipe:[222536390]
Это говорит, что стандартный вывод 4242 PID (FD 1, условно) подключен к каналу с inode номером 222536390, и что вход стандарта 4243 PID (FD 0) подключен к тому же каналу.
Весь из которого является длинным путем сказать это ls
вывод отправляется в less
вход.
Возвращаясь к Вашему примеру, FD 1 и FD 2 почти наверняка не говорят друг с другом. Скорее всего, это - результат связи stdout (FD 1) и stderr (FD 2) вместе, таким образом, они оба переходят к тому же месту назначения. Можно сделать это с Оболочкой Bourne как это:
$ some-program 2>&1 | some-other-program
Так, если Вы ввели по абсолютному адресу вокруг в /proc/$PID_OF_SOME_OTHER_PROGRAM/fd
, Вы прилагается бы третий фарадей к каналу с тем же inode числом, как присоединен к FDs 1 и 2 для some-program
экземпляр. Это может также быть тем, что происходит с FDs 5 и 6 в Вашем примере, но у меня нет готовой теории, как эти два FDs были связаны. Необходимо было бы знать то, что программа делает внутренне для понимания этого.
Страницы справочника для стандартной библиотеки для C включены в man-pages
пакет. Для библиотеки STL C++ страницы справочника и документация HTML включены в libstdc++-docs
пакеты. Таким образом,
yum install man-pages libstdc++-docs
должен установить их. Можно протестировать, если они доступны через:
man std::iostream
man fopen
Отчасти вне темы: по моему скромному мнению, libstdc ++ документация (особенно страницы справочника) не настолько удобна для обзора - я обычно использую http://en.cppreference.com/w/, который очень удобен для навигации и актуальный - или я использую интегрированную функцию поиска, или я использую поиск Google как 'ссылка C++ iostream', и первый хит обычно указывает на страницу cppreference.com так или иначе. Это также доступно как офлайновая копия.
Править: Протестированный man std::iostream
на поле FC 14 с libstdc++-docs
установленный, и удивительно, это не могло найти его.
Используя yum povides '*/std::iostream*'
печать, что libstdc++-docs
пакет обеспечивает соответствующий файл страницы справочника, но он устанавливает его на необычном местоположении:
/usr/share/man/man3/man3/std::iostream.3.gz
Таким образом, вызов man
как
man -M /usr/share/man/man3 std::iostream
показывает страницу справочника.
Похож на ошибку в FC 14 libstdc++-docs
пакет мне.
yum provides '*/fopen.3*'
скажет Вам, какой пакет доступен, который содержит названный файл fopen.3*
(т.е. fopen
страница справочника). (спасибо maxschlepzig)
yum provides fopen.3
указал бы, который пакет содержитfopen
страница справочника, но по-видимому это неправильно. Что Fedora является (вкусным) эквивалентом (Кв.) Debianapt-file search fopen.3
? – Gilles 'SO- stop being evil' 07.05.2011, 15:33yum provides '*/fopen.3*'
- без globing это не ищет имена файлов. – maxschlepzig 07.05.2011, 17:55