La barre oblique / est le caractère de délimitation qui sépare les répertoires dans les chemins dans les systèmes d'exploitation de type Unix. Ce caractère 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 le > caractère comme séparateur de chemin, mais les concepteurs d'Unix avaient déjà réservé les caractères > et < pour signifier la redirection d'E / S sur la ligne de commande du shell bien avant qu'ils n'aient un système de fichiers à plusieurs niveaux. Ainsi, lorsque le moment est venu de concevoir le système de fichiers, ils ont dû trouver un autre caractère pour signifier la séparation des éléments du nom de chemin.
Une chose à noter ici est que dans le terminal Lear-Siegler ADM-3A couramment utilisé dans les années 1970, d'où entre autres la pratique d'utiliser le ~ caractère pour représenter l'origine du répertoire personnel, le / la clé est à côté de > clé :
Quant à savoir pourquoi le répertoire racine est désigné par un seul / , il s'agit d'une convention très 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, et bien que d'autres répertoires puissent se trouver en dessous, il n'y a généralement aucune raison de se référer à quoi que ce soit 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 « A General-Purpose File System For Secondary Storage » par R.C. Daley et P.G. 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 du fichier forme une arborescence, dans laquelle tous les nœuds non feuilles sont des répertoires. La racine de l'arborescence est toujours un répertoire. Chaque fichier a un nom (le nom de l'entrée) qui est unique dans son répertoire parent. Le répertoire racine n'a pas de nom car il n'est pas contenu dans un autre répertoire.
Pour désigner un fichier, vous devez décrire le chemin à partir de la racine de l'arborescence. Multics a adopté une syntaxe naturelle pour les noms de chemin où if P est le chemin vers un répertoire et F est le nom d'un fichier, puis P>F est la syntaxe du fichier appelé F dans le répertoire dont le chemin est P .
Pour les moments où vous ne voulez pas vous encombrer de répertoires, Multics avait une notion de répertoire de travail. Un nom de fichier nu sans indication de répertoire est interprété comme un fichier dans le répertoire de travail.
En combinant ces règles, foo est un fichier dans le répertoire de travail ; foo>bar est un fichier dans le répertoire enfant foo du répertoire de travail, etc. Ces règles décrivent des chemins relatifs, mais une règle supplémentaire est nécessaire pour construire des chemins absolus à partir du répertoire racine. Étant donné que lire un nom de chemin de gauche à droite correspond à se déplacer 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 fichiers ne sont jamais vides (ce qui serait souvent déroutant), 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. Ainsi >foo est le fichier nommé foo dans le répertoire racine, >foo>bar est le fichier nommé bar dans le répertoire nommé foo dans 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, donc à la place, il est écrit > , qui a l'avantage supplémentaire qu'un nom de chemin est absolu si et seulement si son premier caractère est > .
Unix a adopté cette conception de Multics. Comme Unix avait déjà utilisé le caractère > pour la redirection de sortie dans son shell de commande, ses concepteurs ont choisi un caractère différent / pour séparer les répertoires dans les noms de chemin.
Dans les composants de nom de chemin sous Unix, seuls deux caractères ne peuvent pas être utilisés :le caractère nul, qui termine les chaînes en C (le langage du noyau) et la barre oblique, qui est réservée comme 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, relatifs et absolus. De plus, on aimerait pouvoir se référer 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 ?
La façon la plus évidente d'étendre un langage (autre que l'introduction d'un nouveau jeton) est de créer une nouvelle syntaxe :donner un nouveau sens aux combinaisons de jetons dont la syntaxe est invalide.
Les chemins qui commencent par une barre oblique n'ont pas de sens, alors pourquoi ne pas utiliser une barre oblique comme marqueur indiquant "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 la signification "le répertoire racine".
Ces deux significations sont liées car un chemin absolu commence la recherche dans le répertoire racine. En d'autres termes, une barre oblique peut être considérée comme ayant le sens :
- naviguez jusqu'au répertoire racine et utilisez le caractère barre oblique.
- s'il y a plus de matériel dans le chemin, traitez-le comme un chemin relatif, sinon vous avez terminé.
Ensuite, nous pourrions tout aussi bien ajouter une barre oblique finale, ce qui peut signifier "ce chemin affirme que le dernier composant du chemin est le nom d'un répertoire plutôt qu'un fichier normal ou tout autre type d'objet :cette barre oblique finale désigne ce répertoire de la même manière que la façon dont la barre oblique indique le répertoire racine."
Avec toute cette syntaxe ci-dessus, nous avons toujours une syntaxe avec une signification non assigné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 le ed l'éditeur n'affiche qu'un ? quand vous faites quelque chose de mal ?) La barre oblique est facile à taper et ne nécessite aucun décalage. Un langage de chemin avec seulement deux types de jetons (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 sous forme de chaîne. Par exemple, nous pouvons "re-raciner" des 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 dollar ou quoi que ce soit d'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 toujours nécessaire dans certains cas lorsqu'il s'agit de chemins de style Unix, mais il y en a moins.