Convention de nommage des fichiers Unix [fermé]

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 existe peut-être une convention de dénomination universelle à suivre.

Par exemple, je veux nommer un fichier dit: backupavec part 2etrandom

Devrais-je le faire comme ceci:

backup_part2_random

OU

backup-part2-random

OU

backup.part2.random

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

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

-ou _est utilisé pour séparer des mots logiques, par exemple my-big-file.txtou parfois my_big_file.txt. -est préférable, car vous n’avez pas besoin d’appuyer sur la touche Maj (du moins avec un clavier d’ordinateur américain standard), d’autres préfèrent _car il ressemble plus à un espace.

Donc, si je comprends votre exemple, backup-part2-randomou backup_part2_randomserait plus proche de la convention Unix normale.

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

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

Par exemple, /usr/binsur 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 dans ce cas, aucun des fichiers commençant par une capitale n'utilise CamelCase:

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

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

Mon point de vue sur les conventions de nom de fichier Unix / Linux:

• Les systèmes de fichiers Unix / Linux ne supportent pas de manière inhérente la notion d'extension. Le concept d'une extension de fichier existe complètement quelque chose pris en charge par les services publics tels que cp, lsou le shell que vous utilisez. Je crois que c'est aussi le cas sur NTFS, mais je peux me tromper.

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

• Tout exécutable de deux lettres est très important. Donc, ne nommez pas vos noms de fichiers exécutables à deux lettres. Tout fichier /etcse terminant en tabest aussi super important, comme fstab, mtab, inittab.
• Parfois .d, les noms de répertoire sont ajoutés, en particulier dans /etc, mais cela n'est pas courant (UPDATE: https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
• rcest largement utilisé pour les scripts ou les fichiers de configuration, en ajoutant des préfixes (par exemple rc.local) ou des suffixes ( .vimrc)
• La communauté Unix / Linux n'a jamais eu une limite de trois caractères sur les extensions et a froncé les sourcils lors du raccourcissement d'extensions bien connues. Par exemple, n'utilisez pas .htmà la fin des fichiers HTML sous Unix / Linux, utilisez .html.
• Dans un ensemble de fichiers, un nom de fichier est parfois mis en majuscule ou en majuscule, il apparaît donc en tête d'une liste de répertoires. L'exemple classique est Makefiledans les packages source. Ne faites ceci que pour des choses comme README.
• ~est utilisé pour identifier un fichier de sauvegarde ou un répertoire, par exemple important_stuff~, ou /etc~. Beaucoup d'obus vont s'étendre d'un seul ~à $HOME.
• Les fichiers de bibliothèque commencent presque toujours par lib. L'exception est zlibet probablement quelques autres.
• Les scripts appelés par inetd sont parfois étiquetés avec un interligne in., tel que in.tftpd.
• La fin de z dans vmlinuzsignifie zippé, mais je n'ai jamais vu d'autre fichier nommé de cette façon.

Sous Unix, nom de fichier est simplement une chaîne, contrairement à DOS, où nom de fichier a été composé à partir du nom et de l'extension. Donc, n'importe quel nom de fichier donné est tout à fait acceptable.

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

Deux pensées:

1. Dans la Naming Variables, Functions, and Filessection des normes de codage GNU, vous trouverez:

   Utilisez des traits de soulignement pour séparer les mots d'un nom, afin que les commandes de mots Emacs puissent leur être utiles. S'en tenir aux minuscules;

   Bien que l'OMI dise "Vous devriez utiliser _parce qu'emacs" semble un peu daté, cela se trouve néanmoins dans le document "normes".

2. Supposons un instant que nous sommes tous d’accord sur le fait que le noyau Linux est le * meilleur * projet de Linux, et que les conventions utilisées ici constituent ce que l’on pourrait qualifier de convention «standard».

   grepsource -ing pour le noyau Linux, vous trouverez ce qui suit:

   • 44,6% du temps, seul le tiret est utilisé
   • 54,1% du temps, seulement le soulignement
   • 1,2% du temps, un fichier utilise les deux.

Fait intéressant, la source pour git pèse 85% pour les tirets, 3,8% pour les traits de soulignement et 11,1% pour les deux.

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

Opinion personnelle: J'utilise des tirets pour des raisons esthétiques et majeures. Si vous travaillez en équipe, votez. Mais pour répéter ce qui a été dit, soyez cohérent .

* ou "be_all and end_all" si vous voulez

Caractères à ne pas utiliser dans les noms de fichiers:

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

Les délimiteurs de caractères que vous devriez utiliser pour rendre les noms plus faciles à lire:

_ -. :

(Dans certains cas, ":" a une signification spéciale cependant)

Pour ajouter à ce que d'autres ont dit, je dirais simplement que, même si les noms de fichiers contiennent des lettres accentuées et de nombreux caractères spéciaux, ils peuvent entraîner 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 personnes (et bien que le courrier électronique soit plutôt efficace 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, même s’il existe de nombreuses façons de les gérer);
• Vous utilisez un partage de fichiers à partir d'un autre ordinateur.

...

Tenez-vous en aux 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 traits d'union (-). Les noms de fichiers sont généralement en minuscules, mais j'utilise CamelCase lorsque le nom du fichier contient plusieurs mots.

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 des programmes, et les shells savent comment exécuter des programmes de différents types. (.Sh) pour les scripts shell et (.pl) pour les scripts perl sont courants mais pas obligatoires. 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 pas les choses si vous l'évitez.

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

Une convention consiste à utiliser "_" pour remplacer les espaces en tant que 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 noms de chemins, donc "_" est généralement préféré.

Les espaces sont légaux dans les noms de chemins, mais sont généralement évités, car ils nécessitent de citer le nom de chemin ("foo bar") ou d'échapper à ces espaces (foo \ bar). Un script de shell correctement écrit citera des variables pouvant inclure des espaces, en particulier des noms de chemins, mais ne pas le faire est un oubli habituel. Il faut beaucoup de frappe lors de la saisie d'une commande unique en ligne de commande.

Utiliser "-" pour séparer des groupes 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 "." 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 de Red Hat Enterprise Linux et de ses dérivés, RPM, s'attend à ce que les fichiers de package se terminent par ".rpm". L'archive tar traditionnelle est un fichier tar (".tar") gzippé (".gz") et se termine ainsi par ".tar.gz".

Ainsi, en réunissant ces éléments, vous vous retrouvez souvent avec des noms de fichiers qui ressemblent à "home_backup_2017-07-01.tar.gz".

utiliser -ou _pour nommer des fichiers
_pour des fonctions
.d'extensions

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

Je suis d’accord avec David Oneill pour dire que vous devriez simplement choisir quelque chose.

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

Lorsque vous utilisez des dates dans des noms, choisissez un format de date standard tel que 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 pourrez simplifier les expressions rationnelles des noms de fichiers ultérieurement.

Votre exemple pourrait alors ressembler à ceci:

backup_2011-06-19T114012___part002___random

Facile à lire et facile à analyser avec des scripts.

Les mots dans un nom de fichier peuvent être séparés avec _ou -selon la convention Unix.

Si vous utilisez -, il est plus facile de taper, vous évite d'appuyer sur MAJ. Mais comme cela -prend si peu de place, il est un peu difficile de lire les séparations de mots par rapport à _. Utiliser _pour séparer les mots donne une apparence beaucoup plus nette, car cela _prend plus de place.

Dans les scripts shell et autres programmes informatiques, _sont utilisés pour les variables de plusieurs mots, comme MY_ENVIRONMENT_FILE. Rendre les noms de fichiers utilisent _aussi bien le maintient constante: MY_ENVIRONMENT_FILE=~/my_environment_file.

En développement Web, il -est préférable de nommer les fichiers. Une des raisons est probablement que le soulignement dans les liens Web peut masquer les traits de soulignement et peut rendre la tâche difficile si vous tapez le lien Web à la main.

Dans la plupart des éditeurs et des pages Web, il this_long_wordest possible de sélectionner entièrement un double clic, mais pas this-long-word.

Il existe certainement une norme pour Linux. Si vous examinez les noms de fichiers sur n’importe quel système Linux, ils sont en minuscules avec des tirets: / usr / bin / ssh-keygen. Ceci est spécifié dans l’un des documents Linux Standards Base que je ne trouve pas pour le moment. Il est également spécifié par GNU qui dit d’utiliser des traits de soulignement pour les noms de variables et des tirets pour les noms de fichiers.

Pour ajouter à ce que tout le monde a dit:

1-Même si Linux ne s’intéresse pas beaucoup aux extensions, Windows l’aime, alors assurez-vous que tous les fichiers que vous envisagez de donner à quelqu'un ont l’extension appropriée.

Les chapeaux 2-Camel semblent être les plus faciles à utiliser avec des scripts, sans caractères spéciaux pour se soucier des séquences d'échappement.