Est-ce que slash (/) fait partie du nom du directory racine de Linux?

La norme POSIX.1-2008 dit

Un path d'access composé d'un seul / doit être résolu dans le directory racine du process. Un path d'access nul ne sera pas résolu correctement.

La norme établit également une distinction entre les noms de files et les paths d'access . / est le nom de path du path du directory racine. Le nom du directory est "le directory racine", mais dans le système de files, il est sans nom.

Pour plus de clarté: / n'est pas le nom du directory racine, mais le path vers celui-ci.

/etc est un autre path. C'est le nom du path absolu vers le directory etc Le nom du directory sur le path /etc est etc

slash est un séparateur ; les noms de directorys n'incluent pas les séparateurs, mais les paths d'access complets incluent les séparateurs.

Donc le "root-level" "/" n'a pas de nom . Sur la plupart des systèmes de type Unix, cela est traité comme un cas particulier comme "." et ".." (bien que bien sûr, il n'y a pas de différence entre les deux à la racine).

La nomenclature peut différer. POSIX, par exemple, répertorie certaines définitions couramment utilisées :

• 3.2 Chemin d'access absolu

  Un path commençant par un ou plusieurs caractères <slash> ; voir aussi Pathname .

• 3.267 Pathname

  Une string qui est utilisée pour identifier un file. Dans le context de POSIX.1-2008, un nom de path peut être limité à {PATH_MAX} octets, y compris l'octet nul de terminaison. Il comporte des caractères de début <slash> facultatifs, suivis par zéro ou plusieurs noms de files séparés par des caractères <slash> . Un nom de path peut éventuellement contenir un ou plusieurs caractères <slash> . Plusieurs caractères <slash> successifs sont considérés comme étant identiques à un <slash> , à l'exception du cas de deux caractères <slash> .

  Remarque: si un nom de path est constitué uniquement d'octets correspondant à des caractères du jeu de caractères de nom de file portable (voir le jeu de caractères de nom de file portable), de caractères <slash> et d'un seul caractère de terminaison <NUL> , le path sera utilisable tous les parameters régionaux pris en charge; Dans le cas contraire, le nom de path ne peut être qu'une string (plutôt qu'une string de caractères). En outre, étant donné que le encoding à un seul octet du caractère <slash> doit être identique pour toutes les locales et ne pas se produire dans un caractère multi-octets, les references à un caractère <slash> dans un path sont bien définies même lorsque le nom de path n'est pas une string de caractères. Cependant, cette propriété ne tient pas nécessairement pour les caractères restants dans le jeu de caractères de nom de file portable.

• 3.268 Composant de path

  Voir Nom de file dans le nom de file .

• 3.170 Nom de file

  Une séquence d'octets composée de 1 octets {NAME_MAX} utilisés pour nommer un file. Les octets composant le nom ne doivent pas contenir les <NUL> ou <slash> . Dans le context d'un nom de path, chaque nom de file doit être suivi d'un caractère <slash> ou d'un <NUL> ; ailleurs, un nom de file suivi d'un <NUL> forme une string (mais pas nécessairement une string de caractères). Les noms de file dot et dot-dot ont une signification particulière. Un nom de file est parfois appelé "composant de nom de path". Voir aussi Pathname .

Alors … si vous cherchez des éclaircissements , ce n'est peut-être pas votre premier arrêt. Des tutoriels tels que cette page Concepts UNIX sont utiles, par exemple, en soulignant que "path complet" est synonyme de path "absolu".

Dans Unix, les files (et les directorys ne sont que des files) n'ont pas de "noms". Les liens ont des noms, les liens sont des inputs dans un directory qui mappent les noms aux files.

Vous pourriez dire que les liens donnent des noms aux files, mais notez: cela implique qu'un file peut avoir plus d'un nom, puisqu'il peut avoir plus d'un lien.

Puisque le directory racine est, bien, le directory racine, il n'y a pas de directory "supérieur" dans lequel il pourrait y avoir un lien, donc il ne peut y avoir de nom associé. Il serait théoriquement possible d'append un lien au directory racine dans un autre directory, mais la plupart des Unix interdisent d'append des liens aux directorys existants, car cela peut conduire à des cycles dans la hiérarchie du système de files dans un graphe est cher, mais ne pas les détecter peut conduire à une récursivité infinie en essayant de résoudre les noms dans le kernel.

Donc, fondamentalement, le directory racine n'a pas de nom, car il n'y a pas de directory au-dessus duquel nous pourrions save le nom.

Comme il a été souligné dans d'autres réponses, nous devons faire la distinction entre un nom et un path (nom). Le directory racine peut être référencé via le path d'access (nom) / .

L'utilisation du mot "nom" est un peu flexible; il peut se référer à un "nom de path complet"; il pourrait se référer à la "input de directory"; il pourrait se référer au "nom de file" passé à diverses fonctions ou routines.

Ainsi, par exemple, /etc/foo et /var/tmp/../../etc/foo et /tmp/../../../../../../foo sont tous des moyens de se référer au même file; ce sont tous des noms valides, comme c'est le cas dans le directory /etc

Revenons à l'essentiel.

Un nom de file dans unix est constitué de composants séparés par le séparateur de directorys / . À peu près la seule ressortingction sur les composants est qu'ils ne peuvent pas contenir les caractères / ou NUL; tout le rest est permis.

Ainsi, le "nom de path complet" de /etc est la string complète: /etc Cela signifie qu'il a le composant etc dans le directory racine.

De même, /x/y/z/foo aurait le composant foo dans le directory /x/y/z .

Maintenant, le directory racine est unique en ce sens qu'il n'a pas de composant dans un directory parent; il a seulement le path complet comme son nom: / .