Règles de syntaxe de chemin

J'écris une bibliothèque pour la manipulation des chaînes de chemin Unix. Cela étant, j'ai besoin de comprendre quelques coins obscurs de la syntaxe dont la plupart des gens ne s'inquiéteraient pas.

Par exemple, mieux que je peux dire, il semble que foo/baret les foo//bardeux vers le même endroit.

En outre, ~représente généralement le répertoire personnel de l'utilisateur, mais que se passe-t-il s'il apparaît au milieu d'un chemin? Que se passe-t-il alors?

Ces questions et plusieurs dizaines d'autres obscures doivent être répondues si je veux écrire du code qui gère correctement tous les cas possibles. Quelqu'un connaît-il une référence définitive qui explique les règles de syntaxe exactes pour ce genre de choses?

(Malheureusement, la recherche de termes tels que "syntaxe de chemin Unix" fait apparaître un million de pages discutant de la $PATHvariable ... Heck, j'ai même du mal à trouver des balises appropriées pour cette question!)

Il existe trois types de chemins:

• chemins relatifs aiment foo, foo/bar, ../a, .. Ils ne commencent pas par /et sont relatifs au répertoire courant du processus effectuant un appel système avec ce chemin.
• chemins absolus comme /, /foo/barou ///x. Ils commencent par 1 ou 3 ou plus /, ils ne sont pas relatifs, sont recherchés à partir du /répertoire racine.
• POSIX permet //food'être traité spécialement, mais ne précise pas comment. Certains systèmes l'utilisent pour des cas particuliers comme les fichiers réseau . Ce doit être exactement 2 barres obliques.

Autre qu'au début, les séquences de barres obliques agissent comme une seule.

~n'est spécial que pour le shell , il est étendu par le shell, ce n'est pas spécial du tout pour le système. La façon dont il est développé dépend du shell. Les shells font d'autres formes d'expansions comme globbing ( *.txt) ou expansion variable /$foo/$barou autres. En ce qui concerne le système est ~foojuste un chemin relatif comme _fooou foo.

À retenir:

• foo/n'est pas le même que foo. Il est plus proche foo/.de foo(en particulier s'il foos'agit d'un lien symbolique) pour la plupart des appels système sur la plupart des systèmes ( foo//est le même que foo/si).
• a/b/../cn'est pas nécessairement le même que a/c(par exemple si a/best un lien symbolique). Le mieux est de ne pas traiter ..spécialement.
• il est généralement sûr de considérer a/././././bla même chose que a/bsi.

Par exemple, autant que je sache, il semble que foo / bar et foo // bar pointent tous les deux au même endroit.

Oui. Ceci est courant car le logiciel concatène parfois un chemin en supposant que la première partie n'a pas été terminée par une barre oblique, donc une est lancée pour s'assurer (ce qui signifie qu'il peut y en avoir deux ou plus). foo///baret foo/////barpointer également vers le même endroit que foo/bar. Une fonction intéressante pour une bibliothèque de manipulation de chemin serait celle qui réduit un nombre illimité de barres obliques séquentielles (sauf au début d'un chemin, où il peut être utilisé de manière URL ou, comme le souligne Stéphane, pour tout but spécial non spécifié).

En outre, ~ représente généralement le répertoire personnel de l'utilisateur

Cette transformation se fait via l' extension du shell et du tilde , qui ne fonctionne que s'il s'agit du premier caractère du chemin. Que vous ayez ou non besoin de gérer cela dépend du contexte. Si la bibliothèque doit être utilisée avec des programmes normaux qui reçoivent, par exemple, des arguments de ligne de commande contenant un chemin, l'expansion du tilde est déjà effectuée lorsqu'ils voient le chemin. La seule situation que je vois être une préoccupation est que vous traitez des chemins directement à partir d'un fichier texte.

Au-delà, ~est un caractère légal dans un chemin * nix et ne doit pas être changé pour autre chose. Selon cela , les seuls caractères qui ne sont pas autorisés dans un nom de fichier Unix sont /(car il s'agit du séparateur de chemin) et "null" (c'est-à-dire un octet zéro) car ils sont généralement illégaux dans le texte.