Quel est le terme technique pour le répertoire actuel (.) Et parent (..)?

20

J'ai obtenu une fonction qui vérifie si le nom de fichier transmis est .ou ... Mais je ne sais pas comment le nommer correctement. Quelque chose comme IsCurrentOrParentDirectory()est ambigu, car la fonction prend un nom de fichier et non un chemin complet. (Intuitivement, un collègue programmeur s'attendrait à ce /usr/que je passe alors que je /usr/reviendrais true, alors que ce n'est pas le cas.)

Existe-t-il un terme technique pour ces entrées d'annuaire? S'il y en a un, c'est quoi?

path technical-writing

— Max Truxa
source

1

. et .. ne sont PAS du tout des noms de fichiers, mais des dossiers. Pourquoi ne vérifiez-vous pas simplement si l'entrée est un fichier valide (le type selon stat () est IF_REG)? PS Ceci est probablement plus adapté à StackOverflow

— Tonny

7

@Tonny .et .. sont des noms de fichiers selon la norme POSIX. Voir ma citation ci-dessous. Je dirais que c'est bien ici car il s'agit de concepts informatiques généraux.

— slhck

Je dois admettre que ma formulation était à nouveau ambiguë. La fonction prend un seul fichier ou de répertoire ( foo.bar, foo...) mais pas un chemin ( foo/bar, /foo/, ...). Mais comme les répertoires, les liens, etc. sont aussi des fichiers, je vais le laisser comme ça.

— Max Truxa

@slhck POSIX l'appelle un fichier, mais le fait pour N'IMPORTE QUEL objet du système de fichiers. Les fichiers dans la terminologie POSIX doivent généralement être lus comme une abréviation de "objet système de fichiers". Au début d'Unix, il dérive de tous les FSO où il y a vraiment des fichiers, mais ce n'est pas vrai pour certaines implémentations modernes et certainement pas pour les systèmes d'exploitation non-Unix, mais conformes à POSIX (Windows NT comme exemple le plus évident). - J'aurais probablement dû écrire "est un fichier normal" au lieu de "fichier valide" dans mon commentaire, mais le commentaire de Max Truxa en fait quand même un point discutable.

— Tonny

23

De la norme POSIX :

Le point de nom de fichier spécial fait référence au répertoire spécifié par son prédécesseur. Le nom de fichier spécial point-point doit faire référence au répertoire parent de son répertoire prédécesseur. Dans un cas particulier, dans le répertoire racine, point-point peut faire référence au répertoire racine lui-même.

Donc, vraiment, si vous voulez vérifier si le nom de fichier est .ou si ..vous devez l'appeler IsDotOrDotDot(), ou, en utilisant la terminologie POSIX de résolution de nom de chemin IsPredecessorOrParentOfPredecessor(), ou peut-être même PointsToPredecessorOrParentOfPrecedessor()... vous avez l'idée. Le problème est que cette dernière terminologie n'a de sens que lorsque l'on regarde les chemins d'accès complets. Mais personne ne comprendrait ça de toute façon.

Considérant que .et ..sont valides (noms de fichiers simplement interprétés différemment), vous devriez juste coller à ce que vous avez, en se fondant sur le qui signifie plutôt que la façon dont ils sont appelés en interne.

— slhck
source

Est-ce .bash_historypoint ou pas point? Je ne sais pas si ce nom de fonction est plus descriptif que l'OP proposé.

— Jens Erat

@JensErat Cela n'a rien à voir avec le problème. La question était de savoir si le composant de nom de fichier était .ou non .., et non pas s'il commençait par un .. Bien sûr, le nom de la fonction de l'OP est plus descriptif; Je lui indiquais simplement à quoi cela fait référence techniquement.

— slhck

2

Bien sûr, mais ne IsDotOrDotDot()dit pratiquement rien sur ce que fait la fonction.

— Jens Erat

"prédécesseur" fait référence à l'élément de chemin immédiatement avant lui dans la spécification de chemin. Si vous regardez simplement les noms des entrées dans un répertoire, "courant" ou "parent" est une meilleure terminologie.

— Simon Richter

2

@JensErat que j'utiliserais IsDotOrDotDot. Toute personne connaissant les concepts du système de fichiers le comprendrait instantanément. Il est discutable que ce .bash_historysoit «point» car aucun contexte n'est alors fourni pour la signification de «point», mais ce n'est certainement PAS «point ou point point».

— kinokijuf

4

.et ..sont généralement utilisés pour décrire des chemins relatifs par rapport à des chemins absolus comme /usr. J'utiliserais cette différence et déclarerais la fonction comme IsRelativeCurrentOrParentDirectory().

Sachez que les références point peuvent se produire n'importe où dans le chemin. Et alors /usr/local/..?

— Jens Erat
source

J'ai omis de souligner que la fonction ne prend qu'un nom de fichier et non un chemin complet. J'ai mis à jour la question en conséquence.

— Max Truxa

2

Le standard POSIX, que slhck ♦ cite utilement, dit:

Le point de nom de fichier spécial fait référence à…. Le nom de fichier spécial point-point doit faire référence à….

(pas d'italique dans l'original). Ainsi, bien que ce ne soit pas exactement technique , il semble que «nom de fichier spécial» pourrait bien être le nom officiel . Vos utilisateurs comprendraient probablement si vous avez appelé votre fonction une des conditions suivantes: IsSpecialDirectory(), IsSpecialFilename()ou tout simplement IsSpecialName().

Ou vous pouvez aller avec IsStandardDirectory(), IsStandardFilename()ou IsStandardName(). Cela suit la convention de dénomination Unix (entrée standard, sortie standard) pour les choses qui sont établies automatiquement pour vous (dans ce cas, par mkfset mkdir). IsAutomatic…()ou IsDefault…(), d'autre part, ne sont probablement pas assez intuitifs.

— Scott
source

En fait, le premier nom que j'ai pris était IsMagicDirectory()donc assez proche de cela, mais je pense que votre formulation est beaucoup plus intuitive et appropriée (d'autant plus qu'elle utilise des conventions de nommage établies). L'utilisation IsSpecialFileNamepourrait même indiquer clairement que la fonction ne reçoit pas un chemin mais un nom de fichier (ou répertoire, lien, etc.) unique.

— Max Truxa

Bonne suggestion. "Spécial" inclurait cependant probablement aussi des liens, des FIFO, etc., non?

— slhck

@slhck: Oui, les périphériques (par exemple, les disques et les ttys) sont appelés «fichiers spéciaux». Et, oui, le terme pourrait être vaguement appliqué aux liens symboliques, aux FIFO et à d'autres habitants exotiques du système de fichiers - tout type de fichier (i-node) autre qu'un «fichier normal». (Oui, les répertoires tombent également dans ce compartiment.) Cela IsSpecialFile()aurait donc été une mauvaise suggestion. Mais je n'ai pas suggéré cela; Ai-je suggéré IsSpecialFilename(). Alors que les noms sda1, console, kmem, myfifoet urandomsont évocateurs, ils ne sont pas réservés et ne sont pas par nature particulière. Mais .et ..sont des noms de fichiers intrinsèquement spéciaux .

— Scott

1

Le seul terme que je connaisse du monde * nix est CWDpour Current Working Directory. C'est en fait assez souvent utilisé. Voir, par exemple, /proc/$$/cwdqui est un lien vers le répertoire à partir duquel vous exécutez la commande.

Je ne connais aucun nom standard pour en ..dehors de dot-dotet comme @slhck l'a souligné, ce n'est pas un bon choix.

— terdon
source

0

Posix est assez ambigu sur le fait de parler des relations d'annuaire parent-enfant. Comme d'autres l'ont dit, ./ ..n'est pas utile pour parler ou communiquer avec d'autres humains.

Les structures de fichiers peuvent être considérées comme une structure de données arborescente. Ici, généralement «parent» et «enfant» ou «fille» sont suffisants pour transmettre un sens. Vous verrez que les manuels de structure de données portent cette convention

Alternativement, il semble que l'on puisse parler des arbres comme "en haut" et "en bas" de l'arbre. Par convention, "up" signifie plus proche du répertoire racine, et "down" fait référence aux enfants.

Je pense que l'une IsCurrentOrUp()ou l' autre IsCurrentOrParent()peut être considérée comme une bonne pratique pour nommer les fonctions.

— CodeOcelot
source