Comment Linux gère-t-il plusieurs séparateurs de chemin consécutifs (/ home //// nom_utilisateur /// fichier)?

Je travaille sur un script python qui transmet les emplacements de fichiers à un sous-processus scp. Tout va bien, mais je suis dans une situation où je pourrais finir par concaténer un chemin avec un nom de fichier tel qu'il y ait un double ' /dans le chemin. Je sais que bash se moque de la présence de plusieurs séparateurs de fichiers, mais je me demande comment cela est rectifié. Est-ce que c'est bash qui enlève des extra /ou est-ce que ça n'a pas vraiment d'importance?

Je demande parce que cela me fera économiser plusieurs lignes de code pour vérifier les /s supplémentaires lors de la concaténation. Je sais que ce n'est pas grave, mais je suis également curieux. J'ai un script bash qui a la ligne cd //usr(au lieu de cd /usr), ce qui semble impliquer qu'il pourrait y avoir une signification à utiliser plusieurs /s dans un chemin

Plusieurs barres obliques sont autorisées et équivalent à une seule barre oblique. A partir de la spécification Single Unix (version 3) , définitions de base §3.266 chemin : «Plusieurs barres obliques successives sont considérées comme identiques à une barre oblique."

Il existe une exception: si un nom de chemin commence par exactement deux barres obliques, il peut être traité différemment (ref: définitions de base, §4.11 résolution du nom de chemin ). Linux lui-même ne fait pas cela, bien que certaines applications le fassent, ainsi que d'autres systèmes unix (par exemple, Cygwin).

Une /fin de chemin à la fin d'un chemin oblige celui-ci à se référer à un répertoire. Dans ( POSIX 1003.1-2001 (v3 Single Unix) définitions de base résolution §4.11 de chemin , une fuite /équivaut à une fuite /.. Posix 1003.1-2008 (Single Unix v4) définitions de base §4.12 supprime l'obligation de rendre équivalent à /., pour pour faire face à des répertoires non existants (par exemple, mkdir foo/est tenu de travailler, alors mkdir foo/.ne serait pas - voir la raison du changement).

Pour les programmes agissant sur une entrée de répertoire, s'il foos'agit d'un lien symbolique vers un répertoire, le passage foo/est un moyen de faire agir le programme sur le répertoire au lieu du lien symbolique.

¹ _{Notez que cela s’applique uniquement à la résolution du chemin, c’est-à-dire lors de l’accès aux fichiers. Les manipulations de nom de fichier peuvent fonctionner différemment. Par exemple basename, dirnameignorez les barres obliques de fin.}

Le système d'exploitation ne semble pas non plus s'en soucier, après avoir juste essayé un programme C avec un appel système direct à ouvrir avec un // dans le chemin.

Vous pouvez utiliser la fonction de bibliothèque python os.path.normpath pour la normaliser, ce qui vous évite de parcourir la chaîne à la recherche d’extras. D'autres langues ont des fonctions similaires.

http://docs.python.org/library/os.path.html#os.path.normpath

Sur tous les systèmes Unix que j'ai vus, c'est la même chose qu'un seul /, mais la norme Unix spécifie que

Un chemin qui commence par deux barres obliques successives peut être interprété de manière définie par l'implémentation, bien que plus de deux barres obliques majeures soient traitées comme une seule barre oblique.

il peut donc être traité spécialement, en fonction de votre système. (Certaines versions Unix plus anciennes utilisaient une double interligne /pour l'accès au système de fichiers distant, et certaines le sont peut-être encore.)

Utilisez-le os.path.joinen Python et vous n'aurez pas plusieurs barres obliques. Construire vous-même les noms de fichiers en concaténant des chaînes est considéré comme un style Python médiocre.

Il n'y a pas de différence.

Les barres obliques multiples sont ignorées (sans effet), par exemple:

ls -al //usr///////bin/sed

Bien sûr, vous pouvez normaliser un chemin avec plusieurs / (barres obliques) possibles en le passant tr -s

NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)

... et ensuite utiliser $NORMALIZED

Cependant, cela devrait être nécessaire. Pour autant que je sache, tout noyau UNIX proprement dit devrait ignorer les séparateurs de chemins concurrents - ou les traiter de manière conceptuelle comme ... /./...