Pourquoi était '.' choisi pour représenter le répertoire actuel et '..' pour le répertoire parent?

33

Après avoir lu cette question, pourquoi «~» a-t-il été choisi pour représenter le répertoire de base? , la question évidente dans mon esprit était de savoir pourquoi. et '..' a été utilisé pour représenter le répertoire courant et le répertoire parent.

Cela semble si intuitif maintenant, mais une raison particulière?

Manu
la source
10
Que des questions ont été posées et répondre à SO
Stéphane Chazelas le

Réponses:

16

Je doute que vous trouviez une réponse aussi intéressante que la question tilde!

Je n'étais pas là, mais .. est comme un ellipsis (...), ce qui a du sens dans des contextes comme cd ../../../there. En outre, et surtout en ce qui concerne le clavier du terminal, il n’ya pas beaucoup de caractères éligibles à cet effet. Vous n'avez pas besoin de passer pour ., non plus. C'est parfait.

Le fait qu'un préfixe point soit utilisé pour les fichiers cachés peut être une autre raison. Les fichiers cachés ne sont pas répertoriés par défaut par des outils tels que ls, de même que les fichiers essentiellement redondants .et ... Redondants dans le sens où il est inutile de les considérer avec d'autres fichiers - ils sont certainement utiles autrement.

Il se trouve que je l’ai peut- être à l'envers ... de wikipedia :

La notion que les noms de fichiers sont précédés d'un '.' devrait être caché est le résultat d'un bogue logiciel dans les premiers jours d'Unix. Quand la spéciale '.' et '..' entrées de répertoire ont été ajoutées au système de fichiers, il a été décidé que la commande ls ne devrait pas les afficher. Cependant, le programme ls a été écrit par erreur pour exclure tout fichier dont le nom commence par un '.', Plutôt que seulement des fichiers nommés '.' ou '..'.

Cela s'avère utile lors de la programmation. puisque le système comprend. et .. en réponse àreaddir() commandes de type (et commandes globales), les ignorer et les fichiers cachés peuvent être réalisés de la même manière.

Une opinion différente à propos de cette valeur d'utilisation se trouve dans la référence de la citation de wikipedia. Bien sûr, toute l'histoire pourrait être apocryphe ... il est un peu difficile de croire que, par exemple, Dennis Ritchie pensait que vérifier le premier caractère serait acceptable.

Je ne suis pas d’accord avec l’auteur, il serait préférable de placer les fichiers de configuration cachés dans leur propre répertoire plutôt que de leur donner un préfixe universel. Le préfixe est beaucoup plus flexible, permettant des directives dans l’arbre comme .gitignoreet .htaccess. Témoin que les fichiers de ce type apparaissent également ensemble lorsqu'ils sont triés lexicographiquement - alors peut-être que c'était exprès après tout .

boucle d'or
la source
3

Surtout la même réponse que @Panos 'sur stackoverflow :

En bref, il a évolué à partir de det dd(le drépertoire et le drépertoire du drépertoire) qui ont été créés manuellement par les utilisateurs. dsont devenus des points , et ceux .-ci ..ont été créés en premier par l' mkdirutilitaire (setuid après que les annuaires de liaison ne sont plus autorisés par un simple utilisateur) et plus tard par l' mkdir appel système.

Extrait d'une entrevue avec Ken Thompson (1989-09-06):

MSM : Mais pour l'utilisateur, cela ressemblerait à peu près à une hiérarchie de répertoires.

Thompson : Non, le premier était un DG. En fait, ce n'était même pas acyclique. Si vous comprenez le système de fichiers UNIX, c'était ... il y avait la liste I, qui est une définition de tous les fichiers du système. Et puis, certains de ces fichiers étaient des répertoires contenant uniquement le nom et le numéro I. Il n'y a rien dedans qui le contraint à un arbre. Donc, ce n'était pas en fait, pas du tout hiérarchique.

MSM : Je vois.

Thompson : Et nous ne l'avons pas limité à un arbre. Nous expérimentions différentes topologies. Ce que nous avons fini par faire est de devenir concret et de forcer les topologies qui étaient en fait les topologies issues de ce système par convention. Le ... Chaque fois que nous avons créé un répertoire, nous le mettons par convention dans un autre répertoire appelé répertoire - répertoire. , qui était dd. Son nom était dd et que tous les répertoires des utilisateurs et en fait la plupart des autres répertoires, les utilisateurs gèrent leur propre système de répertoires, avaient des pointeurs sur dd, et dd a été raccourci en point-point, et dd était pour répertoire-répertoire. C'était l'endroit où vous pouviez accéder à tous les autres répertoires du système pour gérer ce bol à spaghettis. Donc, je veux dire ce tuf sous différentes formes, ce qui était strictement conventionnel dans cette mise en œuvre par DG d'un ensemble de répertoires et de fichiers au hasard, a été forcé dans une typologie que nous avons maintenue. Lorsque nous avons commencé à écrire des choses telles que la vérification des programmes de fichiers et autres choses dans les systèmes de fichiers, le verrouillage des répertoires de spaghettis et la recherche de choses incohérentes, je veux dire que vous fouilliez quelque chose sans jamais le récupérer, car vous saviez que vous l'aviez perdu. Ces problèmes sont devenus presque insurmontables et, par conséquent, lors de la prochaine mise en œuvre, nous avons imposé une typologie plus forte que celle-là.

Stéphane Chazelas
la source