Une variable de chemin de répertoire doit-elle se terminer par une barre oblique de fin?
Lors de la définition d'un chemin d'accès à un répertoire en tant que variable ou constante, doit-il se terminer par une barre oblique de fin? Quelle est la convention?
pwd sous unix affiche votre répertoire actuel sans barre oblique, tandis que l'onglet complet de cd /var/www/apps/ inclut la barre oblique de fin, ce qui m'a laissé incertain.
Je n'inclus pas la barre oblique de fin lorsque je définis par exemple un répertoire pour stocker des fichiers. C'est parce que je vais l'utiliser comme
$store_file = "$store_path/$file_id";
J'ajouterai toujours une barre oblique avant d'utiliser une variable qui est censée contenir un chemin de répertoire. Je pense qu'il vaut toujours mieux en ajouter un que de se demander si la barre oblique de fin est incluse.
Je choisis la barre oblique car:
"S'il se termine par une barre oblique, c'est un répertoire. Sinon, c'est un fichier." est une convention facile à retenir.
Au moins sur les systèmes d'exploitation que j'utilise couramment, doubler la barre oblique ne pose aucun problème, tandis que l'omission de la barre oblique en provoque de gros. Il est donc plus sûr à la fois de mettre la barre oblique dans la variable et d'utiliser "$ path/$ file" lors de son utilisation.
Oui, cela devrait, car:
Chemin d'accès + nom de fichier = emplacement de fichier complet.
Donc, la barre oblique entre le dernier répertoire et le nom de fichier doit être à la fin du nom de chemin ou au début du nom de fichier. Préfixer les noms de fichiers avec un/signifie que vous devez en tenir compte si vous souhaitez simplement ouvrir un fichier (c'est-à-dire si vous supposez qu'un nom de fichier non qualifié se trouve dans le répertoire de travail actuel).
Chaque fois que je stocke des chemins de répertoire ou les renvoie à partir d'API, j'essaie de respecter la convention de conserver une barre oblique de fin. Cela évite toute ambiguïté "est-ce un fichier ou un répertoire".
Addendum:
Ceci n'est pas destiné à se substituer à l'utilisation de méthodes pouvant tolérer une barre oblique de fin ou son absence. Même en utilisant cette convention, j'utilise toujours Path.Combine(...) et des méthodes similaires.
Vous devriez peut-être réfléchir à ce que votre décision signifierait pour les fichiers. Si vous n'incluez pas la barre oblique à la fin d'un nom répertoire, vous devrez l'ajouter au début du nom fichier.
Maintenant, si pour une raison quelconque le chemin menant au fichier est manquant lorsque vous concaténez des chaînes, vous vous retrouvez avec quelque chose comme /filename qui n'est pas seulement un fichier mais un chemin absolu depuis le répertoire racine (où que ce soit dans ce contexte).
C'est pourquoi je termine mes chemins avec une barre oblique et garde les fichiers en tant que fichiers.
Je sais que cela a 10 ans, mais je voulais jeter mon 0,02 $ très opiniâtre.
Non. Absolument pas.
Nous parlons d'un système Unix. En référence au répertoire lui-même, c'est un nœud comme les autres. Lorsqu'il fait référence au répertoire, il ne doit jamais avoir de barre oblique non échappée dans son nom (ref: dirname, pwd, ~, echo $HOME, echo $PATH, la sortie de ls, et al).
Lorsque vous vous référez au contenu d'un répertoire, alors vous avez besoin d'une barre oblique. C'est-à-dire, ls /home/karl/ est plus approprié que ls /home/karl (FTR, je fais presque toujours ce dernier parce que ... enfin, paresseux).
Lorsque vous utilisez une variable contenant un répertoire pour créer le chemin d'accès complet à un fichier, vous vous attendez toujours à inclure la barre oblique (i., E: cp ${HOME}/test ${OTHER_DIR}/).
C'est attendu qu'un répertoire ne se termine pas dans une barre oblique. Toute attente qu'un répertoire se termine par une barre oblique est fausse. Ajoutant ainsi une barre oblique à la fin d'un *_DIR la valeur de la variable renverserait les attentes.
Est-il intéressant de noter que ce n'est pas parce que c'est faux que les outils/packages/bibliothèques ne le font jamais. Il est bien trop courant que de telles choses ajoutent une barre oblique de fin quand aucune ne devrait exister. Par conséquent, comme Bevan et Paul F ont tous deux suggéré, lors de l'utilisation d'outils tiers, il est préférable de supprimer toutes les barres obliques qui pourraient exister dans les noms de répertoire.
Inodes Unix
L'inode (nœud d'index) est une structure de données dans un système de fichiers de style Unix qui décrit un objet de système de fichiers tel qu'un fichier ou un répertoire.
- https://en.wikipedia.org/wiki/Inode
Norme de hiérarchie du système de fichiers
Le standard pour le système de fichiers Unix (Filesystem Hierarchy Standard, AKA FHS) montre clairement que les répertoires ne sont pas considérés comme ayant une barre oblique de fin, mais que le contenu du répertoire commence par une barre oblique (la seule exception à ceci est / parce que nous ne ferons pas référence à la racine du système de fichiers en utilisant une chaîne vide ... et on ne devrait jamais y créer de fichiers de toute façon.)
- http://www.pathname.com/fhs/pub/fhs-2.3.html
- https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
En php, puisque la fonction dirname (__ FILE __) renvoie le nom du répertoire sans barre oblique à la fin. J'ai tendance à m'en tenir à cette convention.
Sinon, l'utilisation d'une barre oblique à la fin d'un nom de répertoire sera en conflit avec la façon dont dirname (..) fonctionne et vous êtes alors obligé de gérer les deux cas car vous ne savez pas si le nom de répertoire provient d'un dirname (.. ) ou un contenu défini avec une barre oblique de fin.
Conclusion: N'utilisez pas de barre oblique car le nom de répertoire (..) ne le fait pas.
// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!
Pour les autres langues, vérifiez la fonction qui extrait un nom de chemin et voyez si elle utilise ou non une barre oblique, puis respectez la convention de la langue.
Je sais que c'est un vieux fil, mais je pensais partager ce que je fais. Si possible, j'autoriserais normalement les deux et ferais quelque chose comme ça (si c'était PHP):
$fullPath = rtrim($directory, '/') . '/filename.txt');
De cette façon, si le répertoire est défini dans un fichier de configuration, peu importe que la prochaine personne à le modifier inclue ou non la barre oblique de fin.
J'ai tendance à simplement ajouter la barre oblique car je vais probablement utiliser ce répertoire pour ajouter/récupérer des fichiers ...
En termes de référencement Web, il peut en fait augmenter les performances en laissant la barre oblique de fin dans
Oui, il existe de nombreux systèmes de fichiers qui prennent en charge les fichiers sans aucune extension, alors ajoutez toujours la barre oblique de fin pour éviter tout problème.
Je n'ai jamais vu de convention ferme de toute façon.
Je suis presque sûr, cependant, que quoi que vous décidiez, quelqu'un d'autre sera sûr à 100% que ce devrait être l'inverse. Donc, la meilleure idée est de tolérer que les choses soient définies de toute façon.
Dans le monde .NET, Path.Combine () vous donne un moyen de gérer cela - il existe des équivalents dans d'autres environnements, à partir des fichiers cmd.