Pourquoi le répertoire racine est-il désigné par un signe /?

95

J'ai effectué des recherches à ce sujet sur Google, mais les résultats étaient nuageux. Pourquoi le /signe désigne-t-il le répertoire racine? Y a-t-il des raisons solides derrière cela?

Ruban Savvy
la source
12
La raison en est que "/" est le séparateur de répertoire et que, même si le répertoire racine lui-même n'a pas de nom, l' cd /homeéquivalent d'un cd /home/ajout /à la fin du nom vide donne accès à ce répertoire.
SF.
2
Avez-vous lu ceci: en.wikipedia.org/wiki/Root_directory ?
Kevdog777
11
Cela n'a pas de nom, car vu de l'intérieur, il constitue la limite de l'arborescence de répertoires visibles. La hiérarchie de répertoires visible peut être simplement un sous-arbre dans une hiérarchie plus large, par exemple lorsque les recherches de noms de chemins ont été modifiées via un chroot()appel, mais que, de l'intérieur, elles sont abstraites.
Thomas Nyman
14
Parce que la chaîne vide aurait été un choix horrible!
Bakuriu
3
En plus de ce qui est mentionné, l'utilisation de / pour indiquer la racine donne certains effets secondaires en termes de noms de chemins absolus et relatifs. /some/dirTOUJOURS signifie (root)/some/dirque tout some/direst toujours relatif au répertoire de travail actuel. Ce principe est également transférable à l’utilisation d’URL Web.
Tor Valamo

Réponses:

108

La barre oblique /est le caractère de délimitation qui sépare les répertoires dans les chemins des systèmes d'exploitation de type Unix. Ce personnage semble avoir été choisi dans les années 1970, et selon des sources anecdotiques , les raisons pourraient être liées au fait que le prédécesseur d'Unix, le système d' exploitation Multics , utilisait ce >caractère comme séparateur de chemin, mais les concepteurs d'Unix l'avaient déjà réservé. les caractères >et <pour signifier la redirection des E / S sur la ligne de commande du shell bien avant qu’ils ne disposent d’un système de fichiers multiniveau. Ainsi, lorsque le moment est venu de concevoir le système de fichiers, ils ont dû trouver un autre caractère pour indiquer la séparation des éléments du chemin.

Il convient de noter ici que, dans le terminal Lear-Siegler ADM-3A couramment utilisé dans les années 1970, d'où provient entre autres la pratique consistant à utiliser le ~caractère pour représenter le répertoire de base , la /clé se trouve à côté de la >clé:

Configuration du clavier du terminal Lear-Siegler ADM-3A

En ce qui concerne la raison pour laquelle le répertoire racine est désigné par un répertoire unique /, il s’agit d’une convention qui est probablement influencée par le fait que le répertoire racine est le répertoire de niveau supérieur de la hiérarchie des répertoires; t une raison de faire référence à quelque chose en dehors du répertoire racine. De même, l'entrée de répertoire elle-même n'a pas de nom, car c'est la limite de l'arborescence de répertoires visible.

Thomas Nyman
la source
2
"Bien que d'autres répertoires puissent être en dessous, il n'y a généralement aucune raison de faire référence à quoi que ce soit en dehors du répertoire racine." Je ne comprends pas ça. Je ne suis pas sûr de la direction que vous entendez par "en dessous", mais il n'y a rien "en dehors" de la hiérarchie /. Les systèmes de fichiers Unix forment une seule arborescence, avec des points de montage pour les différents lecteurs.
alexis
4
Il y a aussi chrootet ainsi - vous ne pouvez accéder à rien en dehors de la nouvelle racine, mais cela ne signifie pas qu'ils ne sont pas là.
Bobson
1
@ Gilles, l'emplacement physique du lecteur n'est pas la question. En ce sens, toute partition de disque se trouve en dehors de la partition racine, mais elle est montée sous root dans la hiérarchie du système de fichiers. Bobson, bon point à propos de chroot, mais cela ne correspond pas à ce que Thomas a dit: après chroot, ce n'est pas que "il n'y a généralement aucune raison" de sortir de la racine du système; c'est impossible. Sous Unix, tout le système de fichiers est sous la racine.
alexis
1
"Après chroot, ce n'est pas" qu'il n'y a généralement aucune raison "de sortir de la racine du système, c'est impossible." C'est tout simplement faux. À l’époque chroot(), il n’avait aucune propriété semblable à une prison , il affectait simplement la résolution du chemin. Même aujourd’hui, les processus privilégiés peuvent sortir d’un ordinateur de leur propre choix . J'ai également mentionné chroot()dans un commentaire précédent .
Thomas Nyman
4
IIRC, la convention Multics utilisée non seulement >comme séparateur de répertoires, mais également <pour désigner le répertoire parent: <en elle-même, équivalente à .., tandis que <fooéquivalente ../foo. J'ai toujours trouvé cela esthétique.
Mark Reed
55

Le premier système de fichiers hiérarchique tel que nous le connaissons aujourd'hui a été conçu pour Multics . La conception est décrite dans «Un système de fichiers polyvalent pour le stockage secondaire» par RC Daley et PG Neumann. Une caractéristique essentielle de ce système de fichiers est qu'un répertoire est un fichier qui peut être contenu dans un répertoire comme n'importe quel autre fichier. La structure de fichier forme un arbre dans lequel tous les nœuds non-feuilles sont des répertoires. La racine de l'arbre est toujours un répertoire. Chaque fichier a un nom (le nom de l' entrée ) unique dans son répertoire parent. Le répertoire racine n'a pas de nom puisqu'il ne figure pas dans un autre répertoire.

Pour désigner un fichier, vous devez décrire le chemin à partir de la racine de l’arbre. Multics a adopté une syntaxe naturelle pour les noms de chemins, où if Pest le chemin d'un répertoire et Fle nom d'un fichier, la syntaxe du fichier appelé dans le répertoire dont le chemin est .P>FFP

Pour les moments où vous ne voulez pas vous encombrer de répertoires, Multics avait la notion de répertoire de travail . Un nom de fichier nu sans indication de répertoire est interprété comme un fichier du répertoire de travail.

La combinaison de ces règles fooconstitue un fichier dans le répertoire de travail; foo>barest un fichier dans le répertoire enfant du répertoire foode travail, etc. Ces règles décrivent les chemins relatifs, mais une règle supplémentaire est nécessaire pour créer des chemins absolus à partir du répertoire racine. Etant donné que lire un nom de chemin de gauche à droite correspond au déplacement de la racine vers les feuilles de l'arbre, la racine doit être indiquée par un marqueur spécial à gauche du nom du chemin. Étant donné que les noms de fichier ne sont jamais vides (car cela créerait souvent de la confusion), aucun nom de chemin relatif ne commence jamais par le caractère >, ce qui en fait un marqueur pratique pour les noms de chemin absolus. C’est donc >foole fichier appelé foodans le répertoire racine, >foo>barle fichier appelé bardans le répertoire appeléfoodans le répertoire racine, etc. Cela laisse le répertoire racine, qui pourrait être la chaîne vide; Cependant, il n'est souvent pas pratique d'utiliser la chaîne vide comme chemin d'accès. Elle est donc écrite >, ce qui présente l'avantage supplémentaire qu'un chemin d'accès est absolu si et seulement si son premier caractère l'est >.

Unix a adopté cette conception de Multics. Unix ayant déjà utilisé le caractère >pour la redirection de la sortie dans son interpréteur de commandes, ses concepteurs ont choisi un caractère différent /pour séparer les répertoires dans les noms de chemins.

Gilles
la source
11

Dans les composants de nom de chemin sous Unix, seuls deux caractères ne peuvent pas être utilisés: le caractère null, qui termine les chaînes en C (le langage du noyau) et la barre oblique, qui est réservée en tant que séparateur de chemin. De plus, les composants de chemin ne peuvent pas être des chaînes vides.

Ainsi, dans un nom de chemin, nous n'avons que deux types de jetons: une barre oblique et un composant.

Supposons que, sans ajouter de nouveaux jetons , nous souhaitons prendre en charge deux types de chemins, relatif et absolu. De plus, nous aimerions pouvoir faire référence au répertoire racine, qui n'a pas de nom (il n'a pas de parent qui lui donnerait un nom).

Comment pouvons-nous représenter des chemins relatifs, des chemins absolus et faire référence au répertoire racine en utilisant uniquement la barre oblique?

Le moyen le plus évident d'étendre un langage (autre que l'introduction d'un nouveau jeton) est de créer une nouvelle syntaxe: donnez un nouveau sens aux combinaisons de jetons qui sont une syntaxe non valide.

Les chemins qui commencent par une barre oblique n’ont pas de sens, alors pourquoi ne pas utiliser une barre oblique comme marqueur qui indique "ce chemin est absolu plutôt que relatif".

Un chemin qui ne contient rien d'autre qu'une barre oblique est également invalide, alors pourquoi ne pas lui attribuer le sens "le répertoire racine".

Ces deux significations sont liées car un chemin absolu commence à chercher dans le répertoire racine. En d'autres termes, une barre oblique peut être considérée comme ayant la signification suivante:

  • accédez au répertoire racine et utilisez le caractère barre oblique.
  • s'il y a plus de matière dans le chemin, traitez-le comme un chemin relatif, sinon vous avez terminé.

Ensuite, nous pourrions aussi bien insérer une barre oblique de fin, ce qui peut vouloir dire "ce chemin indique que le dernier composant de chemin est le nom d'un répertoire plutôt qu'un fichier normal ou tout autre type d'objet: cette barre oblique de fin indique ce répertoire de la même manière que la façon dont la barre oblique principale indique le répertoire racine. "

Avec toute la syntaxe ci-dessus, nous avons toujours une syntaxe avec une signification non attribuée: doubles barres obliques, triples barres obliques, etc.

Pourquoi ne pas simplement introduire un autre jeton et le faire différemment. C'est probablement parce que les concepteurs ont adopté des approches minimalistes en général. (Pourquoi l’ edéditeur n’affiche-t-il un a ?lorsque vous faites quelque chose de mal?) Une langue de chemin avec seulement deux types de jeton (composant et barre oblique) est facile à mémoriser et à utiliser.

Une autre considération importante est que des manipulations faciles des chemins sont possibles en utilisant uniquement des représentations de chaîne. Par exemple, nous pouvons "re-root" les chemins absolus vers un nouveau répertoire parent assez facilement:

OLD_PATH=/old/path
NEW_HOME=/new/home

NEW_PATH="$NEW_HOME$OLD_PATH"  /new/home/old/path

Cela ne fonctionnerait pas si nous indiquions des chemins absolus d'une autre manière, comme un signe de dollar fort ou autre:

OLD_PATH=^old/path  # ^ means absolute path
NEW_HOME=^new/home

# now we need more string kung-fu than just catenation
NEW_PATH="$NEW_HOME/${OLD_PATH#^}"

Ce type de codage est encore nécessaire dans certains cas lorsqu'il s'agit de chemins de style Unix, mais il en existe moins.

Kaz
la source
8
"La barre oblique est facile à taper et ne nécessite aucun changement." Peut-être que vous arrivez facilement de l'autre côté de l'étang, mais ici, en Finlande, nous devons non seulement appuyer sur Shift, mais aussi atteindre tous les numéros . ; P
Thomas Nyman
1
@ThomasNyman Quoi qu'il en soit, les configurations de clavier étranger ne sont probablement pas une préoccupation pour Ken Thompson. La barre oblique était facile à saisir pour les développeurs Unix et leurs premiers utilisateurs.
Kaz
1
C'est suffisant. Bien que je plaisante surtout, je trouve intéressant (et parfois amusant) de voir certaines particularités des logiciels avec un long héritage pouvant s’expliquer par les particularités des matériels contemporains .
Thomas Nyman
@ThomasNyman Haha, je me demande si Bill Joy lui-même se connecte et met à jour les parties {citation-required} de cette page ADM-3A. Certains "Wikidickhead" seront-ils alors contre ": cet article contient des recherches originales". :)
Kaz
@ThomasNyman, Maintenant, je crois qu'il existe des claviers "à pédale" grâce auxquels vous pouvez taper à l' /aide du pied droit. Juste comme jouer d'un piano.
Pacerier