Portabilité des liens de descripteur de fichier ?

Je me suis toujours posé la question, mais je n'ai jamais pris le temps de le découvrir, alors je vais le faire maintenant - dans quelle mesure l'utilisation montrée ici de /proc/$$/fd/$N est-elle portable ? ou /dev/fd/$N ? Je comprends que POSIX garantit /dev/null, /dev/tty, and /dev/console (même si je ne l'ai découvert que l'autre jour après avoir lu les commentaires sur cette réponse) mais qu'en est-il de ces autres ?

Pour autant que je sache, ils sont assez courants, mais dans quels systèmes puis-je pas espérer les trouver ? Pourquoi pas? Est-il plus probable d'en trouver un que l'autre ? Présenteront-ils toujours des attributs similaires ?

J'ai tendance à utiliser ces appareils de manière assez intensive de toutes sortes de façons, et j'aimerais savoir s'il y a une chance que je tombe à court rien qu'en essayant.

De plus, les questions ci-dessus doivent être comprises comme n'étant que ce que je pense J'aimerais savoir, mais, puisque je dois évidemment demander en premier lieu, je ne suis peut-être pas le meilleur à cet égard et ils ne devraient pas être considérés comme des exigences strictes pour une réponse. Donnez-moi juste un indice si vous le pouvez, s'il vous plaît.

Réponse acceptée :

Le /proc/PID/fd/NUM les liens symboliques sont quasi-universels sous Linux, mais ils n'existent nulle part ailleurs (sauf sur Cygwin qui les émule). /proc/PID/fd/NUM existent également sur AIX et Solaris, mais ce ne sont pas des liens symboliques. De manière portable, pour obtenir des informations sur les fichiers ouverts, installez lsof .

Unices avec `/proc/PID/fd`

Linux

Sous Linux, /proc/PID/fd/NUM est un lien symbolique un peu magique vers le fichier que le processus a pour ID PID a ouvert sur le descripteur de fichier NUM . Ce lien est magique dans la mesure où, par exemple, il peut être utilisé pour accéder au fichier même si le fichier est supprimé. Le lien suivra également le fichier à travers les renommages. /proc/self est un lien symbolique magique qui pointe vers /proc/PID où PID est le processus qui accède au lien.

Cette fonctionnalité est présente sur pratiquement tous les systèmes Linux. Il est fourni par le pilote du système de fichiers proc, qui est techniquement facultatif mais utilisé pour tant de choses (y compris la création du ps fonctionne - il lit à partir de /proc/PID ) qu'il n'est presque jamais oublié, même sur les systèmes embarqués.

Cygwin

Cygwin émule le /proc/PID/fd/NUM (pour les processus Cygwin) et /proc/self .

Solaris (depuis la version 2.6), AIX

Il y a /proc/PID/fd entrées pour chaque descripteur de fichier, mais elles apparaissent comme étant du même type que le fichier ouvert, elles ne fournissent donc aucune information sur le chemin du fichier. Ils rapportent cependant la même stat informations sous forme de fstat rendrait compte au processus qui a le fichier ouvert, il est donc possible de déterminer sur quel système de fichiers se trouve le fichier et son numéro d'inode. Les répertoires apparaissent comme des liens symboliques, mais ce sont des liens symboliques magiques qui ne peuvent être suivis, et readlink renvoie une chaîne vide.

Sous AIX, les procfiles La commande affiche des informations sur les fichiers ouverts d'un processus. Sous Solaris, les pfiles La commande affiche des informations sur les fichiers ouverts d'un processus. Cela n'inclut pas le chemin d'accès au fichier (sur Solaris, c'est le cas depuis Solaris 10, voir ci-dessous).

Solaris (depuis la version 10)

En plus de /proc/PID/fd/NUM , les versions modernes de Solaris ont /proc/PID/path/NUM qui contient des liens symboliques similaires aux liens symboliques de Linux dans /proc/PID/fd/NUM . Les pfiles La commande affiche des informations sur les fichiers ouverts d'un processus, y compris les chemins.

Plan9

/proc/PID/fd est un fichier texte qui contient un enregistrement (ligne) par descripteur de fichier ouvert par le processus. Le nom du fichier n'y est pas suivi.

En relation :Extraire le nom du fichier du chemin dans le programme awk ?

QNX

/proc/PID/ est un répertoire, mais il ne contient aucune information sur les descripteurs de fichiers.

Unices avec `/proc` mais pas d'accès direct aux descripteurs de fichiers

(Remarque :il est parfois possible d'obtenir des informations sur les fichiers ouverts d'un processus en parcourant son image mémoire accessible sous /proc . Je ne considère pas cela comme un "accès direct".)

Unices où `/proc/PID` est un fichier

Le système de fichiers proc lui-même a commencé dans UNIX 8e édition, mais avec une structure différente, et est passé par le plan 9 et est revenu à certains unices. Je pense que tous les systèmes d'exploitation avec un /proc avoir une entrée pour chaque PID, mais sur de nombreux systèmes, c'est un fichier normal, pas un répertoire. Les systèmes suivants ont un /proc/PID qui doit être lu avec ioctl :

Solaris jusqu'à 2.5
OSF/1 désormais connu sous le nom de Tru64
IRIX (?)
SCO (?)

MINIX 3

MINIX 3 dispose d'un serveur procfs qui fournit plusieurs composants de type Linux, notamment /proc/PID/ répertoires. Cependant il n'y a pas de /proc/PID/fd .

FreeBSD

FreeBSD a /proc/PID/ répertoires, mais ils ne fournissent pas d'informations sur les descripteurs de fichiers ouverts. (Il y a cependant /proc/PID/file qui est similaire au /proc/PID/exe , donnant accès à l'exécutable par un lien symbolique.)

Le procfs de FreeBSD est obsolète.

Unices sans `/proc`

HP-UX
OpenBSD
NetBSD
Mac OS X

Informations sur le descripteur de fichier via d'autres canaux

Fuseur

Le fuser La commande répertorie les processus qui ont un fichier spécifié ouvert ou un fichier ouvert sur le point de montage spécifié. Cette commande est standard (disponible sur tous les systèmes compatibles XSI, c'est-à-dire POSIX avec l'extension X/Open System Interface).

Vous ne pouvez pas passer d'un processus à des noms de fichiers avec cet utilitaire.

Lsof

Lsof signifie "liste des fichiers ouverts". Il s'agit d'un outil tiers, disponible (mais ne faisant généralement pas partie de l'installation par défaut) pour la plupart des variantes Unix. L'obtention d'informations sur les fichiers ouverts est très dépendante du système, comme l'analyse ci-dessus aurait pu vous faire suspecter. Le responsable de lsof a fait le travail de tout combiner sous une seule interface.

Vous pouvez lire la FAQ pour voir quels types de difficultés lsof doit supporter. Sur la plupart des unix, l'obtention d'informations sur les noms des fichiers ouverts nécessite l'analyse des structures de données du noyau. Citant la FAQ 3.3 "Pourquoi lsof ne signale-t-il pas les noms de chemin complets ?" :

Lsof ne peut pas obtenir les composants de nom de chemin à partir des caches de noms de noyau des dialectes suivants :

AIX

Seul le noyau Linux enregistre les noms de chemin complets dans les structures qu'il maintient à propos des fichiers ouverts; à la place, la plupart des noyaux convertissent les noms de chemin en doublets de numéro de périphérique et de nœud et les utilisent pour les références de fichiers ultérieures une fois les fichiers ouverts.

Si vous avez besoin d'analyser les informations de lsof la sortie, assurez-vous d'utiliser le -F mode (un champ par ligne), de préférence le -F0 mode (champs délimités par des nuls). Pour obtenir des informations sur un descripteur de fichier spécifique d'un processus spécifique, utilisez le -a option avec -p PID et -d NUM , par exemple. lsof -a -p 123 -d 0 -F0n .

`/dev/fd/NUM` pour les descripteurs de fichier du processus en cours

De nombreuses variantes Unix permettent à un processus d'accéder à ses fichiers ouverts via un nom de fichier :ouverture de /dev/fd/NUM est équivalent à appeler dup(NUM) . Ces noms sont utiles lorsqu'un programme veut un nom de fichier mais que vous voulez passer un fichier déjà ouvert (par exemple un tube ou un socket) ; par exemple, les shells qui implémentent la substitution de processus les utilisent lorsqu'ils sont disponibles (en utilisant un canal nommé temporaire où /dev/fd n'est pas disponible).

Où /dev/fd existe, il y a aussi généralement (toujours ?) des synonymes (parfois des liens symboliques, parfois des liens physiques, parfois des fichiers magiques avec des propriétés équivalentes) /dev/stdin =/dev/fd/0 , /dev/stdout =/dev/fd/1 , /dev/stderr =/dev/fd/2 .

Sous Linux, /dev/fd est un lien symbolique vers /proc/self/fd .
Sous la plupart des unices (IRIX, OpenBSD, NetBSD, SCO, Solaris, …), les entrées dans /dev/fd sont des périphériques de caractères. Ils apparaissent généralement que le descripteur de fichier soit ouvert ou non, et les entrées peuvent ne pas être disponibles pour les descripteurs de fichier au-delà d'un certain nombre.
Sous FreeBSD et OSX, le système de fichiers fdescfs fournit un /dev/fd dynamique répertoire qui suit les descripteurs ouverts du processus appelant. Un /dev/fd statique est disponible si /dev/fd n'est pas monté.
Sous OSF/1 (Tru64), /dev/fd est fourni via fdfs.
Il n'y a pas de /dev/fd sous AIX ou HP-UX.

Connexe :Est-il possible d'obtenir un caractère au curseur du terminal en utilisant les codes d'échappement ANSI ?