it-swarm-fr.com

Convention de dénomination des fichiers Unix

Je me demandais quelle est la convention de dénomination des fichiers sous Unix? Je ne suis pas sûr de cela, mais je pense qu'il y a peut-être une convention de dénomination universelle que l'on devrait suivre?

Par exemple, je veux nommer un fichier, dites: backup avec part 2 et random

Dois-je le faire comme ceci:

backup_part2_random

OR

backup-part2-random

OR

backup.part2.random

J'espère que la question est claire. Fondamentalement, je veux choisir un format conforme à la philosophie Unix.

67
user4740

. est utilisé pour séparer une extension de type de fichier, par exemple foo.txt.

- ou _ est utilisé pour séparer les mots logiques, par exemple my-big-file.txt ou parfois my_big_file.txt. - est mieux parce que vous n'avez pas à appuyer sur la touche Maj (au moins avec un clavier PC anglais américain standard), d'autres préfèrent _ car il ressemble plus à un espace.

Donc, si je comprends votre exemple, backup-part2-random ou backup_part2_random serait le plus proche de la convention Unix normale.


CamelCase n'est normalement pas utilisé sur les systèmes Linux/Unix. Jetez un œil aux noms de fichiers dans /bin et /usr/bin. CamelCase est l'exception plutôt que la règle sur les systèmes Unix et Linux.

(NetworkManager est le seul exemple auquel je peux penser qui utilise CamelCase, et il a été écrit par un développeur Mac. Beaucoup se sont plaints de ce choix de nom. Sur Ubuntu, ils ont en fait renommé le script en network-manager.)

Par exemple, le /usr/bin sur mon système:

$ ls -d [A-Z]* | wc -w    # files starting with a capital
6
$ ls -d *_* | wc -w       # files containing an underscore
178
$ ls -d *-* | wc -w       # files containing a minus/dash
409

et même alors, aucun des fichiers commençant par une majuscule n'utilise CamelCase:

$ ls -d [A-Z]*
GET  HEAD  POST  X11  Xvnc  Xvnc4
61
Mikel

loin plus important qu'une convention particulière soit cohérente. Choisissez un style et respectez-le.

38
David Oneill

Mon point de vue sur les conventions de noms de fichiers Unix/Linux:

  • Les systèmes de fichiers Unix/Linux ne supportent pas intrinsèquement la notion d'extension. Le concept d'une extension de fichier existe complètement comme quelque chose pris en charge par des utilitaires tels que cp, ls, ou le shell que vous utilisez. Je pense que c'est également le cas sur NTFS, mais je peux me tromper.

  • Les exécutables, y compris les scripts Shell, n'ont généralement aucun type d'extension. Les scripts auront une ligne de hachage (c'est-à-dire #!/bin/bash) Qui identifie le programme qui doit l'interpréter.

  • Tout exécutable de deux lettres est super important. Ne nommez donc pas vos fichiers exécutables à deux lettres. Tout fichier dans /etc Se terminant par tab est également très important, comme fstab, mtab, inittab.
  • Parfois, .d Est ajouté aux noms de répertoire, en particulier dans /etc, Mais ce n'est pas répandu (MISE À JOUR: https://serverfault.com/questions/240181/what-does -le-suffixe-d-signifie-dans-linux )
  • rc est largement utilisé pour les scripts ou fichiers de configuration, soit en préfixe (par exemple, rc.local) soit en suffixe (.vimrc)
  • La communauté Unix/Linux n'a jamais eu une limite de trois caractères sur les extensions et fronce les sourcils en raccourcissant les extensions bien connues. Par exemple, n'utilisez pas .htm À la fin des fichiers HTML sur Unix/Linux, utilisez .html.
  • Dans un ensemble de fichiers, un nom de fichier est parfois en majuscule, ou en majuscules, il apparaît donc en tête d'une liste de répertoires. L'exemple classique est Makefile dans les packages source. Ne faites cela que pour des choses comme README.
  • ~ Est utilisé pour identifier un fichier de sauvegarde ou un répertoire, comme dans important_stuff~ Ou /etc~. De nombreux shells vont développer un seul ~ À $HOME.
  • Les fichiers de bibliothèque commencent presque toujours par lib. L'exception est zlib et probablement quelques autres.
  • Les scripts qui sont appelés par inetd sont parfois marqués d'un in., Tel que in.tftpd.
  • Le z final dans vmlinuz signifie zippé, mais je n'ai jamais vu d'autre fichier nommé de cette façon.
19
LawrenceC

Dans unix, le nom de fichier est juste une chaîne, contrairement à DOS, où le nom de fichier a été composé à partir du nom et de l'extension. Donc, n'importe lequel des noms de fichiers donnés est tout à fait acceptable.

Mais de nombreux programmes utilisent toujours des suffixes de fichiers commençant par un point pour distinguer différents types de fichiers, c'est-à-dire qu'Apache Web Server utilise des suffixes pour définir le type MIME correct dans les en-têtes de réponse.

7
gelraen

Deux réflexions:

  1. Dans le Naming Variables, Functions, and Files section des GNU Coding Standards vous trouverez:

    Veuillez utiliser des traits de soulignement pour séparer les mots d'un nom, afin que les commandes Emacs Word puissent être utiles en leur sein. Tenez-vous en minuscules;

    Alors que l'OMI disait "Vous devriez utiliser _ parce qu'emacs "semble un peu daté, c'est quand même dans leur document" standards ".

  2. Supposons un instant que nous convenions tous que le noyau linux est le tout-et-tout-fin * des projets linux, et que les conventions utilisées là-bas sont ce qui pourrait être considéré comme une convention "standard".

    grep- ing source pour le noyau linux vous trouverez ce qui suit:

    • 44,6% du temps seul le tiret est utilisé
    • 54,1% du temps soulignent uniquement
    • 1,2% du temps où un fichier utilise les deux.

Fait intéressant, le source pour git pèse 85% pour les tirets, 3,8% pour les tirets bas et 11,1% pour les deux.

Le choix est clair, débat terminé. ;)

Opinion personnelle: J'utilise des tirets pour des raisons essentielles esthétiques et de décalage. Si vous travaillez en équipe, votez. Mais pour réitérer ce qui a été dit, soyez cohérent.

* ou "be_all et end_all" si vous voulez

6
Roy Truelove

Caractères que vous ne devez pas utiliser dans les noms de fichiers:

| ; ,! @ # $ () <>/\ "'` ~ {} [] = + & ^

Délimiteurs de caractères à utiliser pour faciliter la lecture des noms:

_ -. :

(Dans certains cas, ":" a cependant une signification particulière)

4
Istvan

Pour ajouter à ce que les autres ont dit, je dirais simplement que même si les lettres accentuées et de nombreux caractères spéciaux sont autorisés dans les noms de fichiers, ils peuvent provoquer des problèmes dans l'un des scénarios suivants:

  • Vous partagez votre système de fichiers avec d'autres ordinateurs, en particulier avec différents systèmes d'exploitation;
  • Vous partagez des fichiers avec d'autres (et bien que le courrier électronique ait tendance à être assez bon avec les conversions, parfois cela ne fonctionne tout simplement pas);
  • Vous utilisez des scripts Shell pour automatiser certaines tâches (les espaces sont particulièrement problématiques, bien qu'il existe de nombreuses façons de les gérer);
  • Vous utilisez un partage de fichiers à partir d'un autre ordinateur.

...

4
asoundmove

Respectez les noms de fichiers alphanumériques. Évitez les espaces ou remplacez les espaces par des traits de soulignement (_). Limitez la ponctuation dans les noms de fichiers aux points (.), Traits de soulignement (_) et tirets (-). Généralement, les noms de fichiers sont en minuscules, mais j'utilise CamelCase lorsque j'ai plusieurs mots dans le nom de fichier.

Utilisez des extensions qui indiquent le type de fichier. Les programmes n'ont pas besoin d'extensions car le bit d'exécution est utilisé pour indiquer les programmes et les shells savent comment exécuter des programmes de différents types. Il est courant mais pas obligatoire de (.sh) pour les scripts Shell et (.pl) pour les scripts Perl. Les extensions exécutables Windows .bat, .com, .scr et .exe indiquent les exécutables Windows sous Unix.

Choisissez un standard et respectez-le. Mais cela ne cassera rien si vous l'évitez.

Les fichiers cachés (ou points) ont des noms commençant par un point. Ceux-ci n'apparaissent normalement pas dans les listes de répertoires. Utilisez 'ls -a' pour inclure les fichiers de points dans la liste.

3
BillThor

utilisation - ou _ pour nommer les fichiers
_ pour les fonctions
. pour les extensions

cat << EOF > foo-bar.sh  
foo_bar() {  
echo baz  
}  
EOF  
2
Akhil Jalagam

Une convention consiste à utiliser "_" pour remplacer les espaces comme séparateurs entre les mots. D'autres caractères pourraient être utilisés pour remplacer les espaces, mais il existe des utilisations conventionnelles légèrement plus fortes pour "-" et "." dans les chemins d'accès, donc "_" est généralement préféré.

Les espaces sont autorisés dans les noms de chemin, mais sont généralement évités, car ils nécessitent de citer le nom de chemin ("foo bar") ou de s'échapper des espaces (foo\bar). Un script Shell correctement écrit cite des variables qui peuvent inclure des espaces, en particulier des noms de chemin, mais à défaut de le faire, c'est une erreur courante, et c'est beaucoup de saisie supplémentaire lors de l'exécution d'une commande unique entrée sur la ligne de commande.

L'utilisation de "-" pour séparer les clusters de nombres, comme dans les horodatages ou les numéros de série, est une convention couramment utilisée en dehors du contexte des systèmes de fichiers. En utilisant "." pour séparer les "extensions de fichier" qui indiquent que le type de fichier est très courant, et certains outils importants en dépendent. Par exemple, le système de gestion de packages sur Red Hat Enterprise Linux et ses dérivés, RPM, s'attend à ce que les fichiers de packages se terminent par ".rpm". L'archive tar traditionnelle est un fichier tar (".tar") qui a été compressé (".gz"), et se termine donc par ".tar.gz".

Donc, en les assemblant, vous vous retrouvez souvent avec des noms de fichiers qui ressemblent à "home_backup_2017-07-01.tar.gz"

2
bgvaughan

Je suis d'accord avec David Oneill sur le fait que vous devriez simplement aller avec quelque chose.

Mais c'est bien si les fichiers sont triables dans le même répertoire, donc ne numérotez pas 0 .. 10 mais nombre 00 .. 10.

Lorsque vous utilisez des dates dans les noms, choisissez un format de date standard comme ISO8601 .

Et n'ayez pas peur d'utiliser plusieurs caractères pour séparer les parties logiques du nom. Si vous utilisez _ (c'était 3 _), vous pouvez simplifier les expressions rationnelles sur les noms de fichiers plus tard.

Ainsi, votre exemple pourrait alors être quelque chose comme ceci:

backup_2011-06-19T114012___part002___random

Facile à lire et à analyser avec des scripts.

0
Johan

Les mots d'un nom de fichier peuvent être séparés par _ ou - selon la convention Unix.

Si tu utilises -, il est plus facile de taper, vous évite d'appuyer sur MAJ. Mais depuis - prend si peu de place, il est un peu difficile de lire les séparations Word par rapport à _. En utilisant _ séparer les mots le rend beaucoup plus propre puisque _ prend plus de place.

Dans les scripts Shell et autres programmes informatiques, _ sont utilisés pour plusieurs variables Word, comme MY_ENVIRONMENT_FILE. Utilisation des noms de fichiers _ maintient également la cohérence: MY_ENVIRONMENT_FILE=~/my_environment_file.

Dans le développement Web, - est préférable pour la dénomination des fichiers. L'une des raisons est probablement que le soulignement des liens Web peut masquer les traits de soulignement et peut compliquer la tâche si vous tapez le lien Web à la main.

Dans la plupart des éditeurs et dans les pages Web, this_long_Word peut être entièrement sélectionné en double-cliquant mais pas this-long-Word.

0
GMaster