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

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?

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é:

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.

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.

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.