Convention de nommage des fichiers Unix [fermé]

61

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.

slm
la source
4
En tant que commentaire général sur les "conventions" ... Je viens de lire toutes les réponses à ce jour, et il m’est étonné de constater qu’il est presque obscur d’utiliser un seul cas dans un système où (je pense) l'un de ses points forts est la capacité d'utiliser judicieusement les deux cas ... Le design d'origine (sensible à la casse) était-il un design supérieur) ... rien que de penser
Peter.O
mon avis: il n'y a pas de convention. Les noms de fichiers ne sont que des chaînes. Choisissez votre style préféré.
Glenn Jackman
1
C'est parce que personne ne veut se souvenir de la capitalisation des commandes, alors ils utilisent tous la même chose.
LtWorf

Réponses:

58

.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
Mikel
la source
Le caractère .peut également être utilisé pour faire pivoter des objets, pas seulement pour spécifier une extension. Par exemple my.log my.log.1 my.log.2.gz.
Depado
Donc, le trait d'union / minus / dash est plus courant que le trait de soulignement.
Hugo
@ Hugo Oui. Ce qui précède montre moins (409) vs trait de soulignement (178).
Mikel
Merci. Avez-vous des références pour ces conventions?
Prolétariat Le
3
+1 pour les références. (@Proletariat, le lsrésultat de /usr/bin est une référence. C'est une question sur les conventions. )
Wildcard
36

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

David Oneill
la source
19

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.
LawrenceC
la source
2
Je vois souvent des scripts shell avec une .sh"extension". Personnellement, je trouve cela un peu agaçant, mais je dois admettre que je peux ne pas savoir pourquoi .sh.
Dan Moulding
4
Une chose me vient à l’esprit, c’est qu’il est utile de souligner le fait qu’il s’agit d’un script basé sur du texte et non d’un fichier binaire.
LawrenceC
1
@DanMoulding, personnellement, j'utilise des .shscripts qui (1) ne sont pas conçus pour être exécutés de manière interactive, mais uniquement à partir d'autres scripts / programmes, ou (2) sont conçus pour le sourçage plutôt que pour l'exécution. Pour les premiers, ils doivent être exécutables; pour ce dernier, je laisse le bit exécutable désactivé et n'utilise la ligne shebang que pour documenter le shell pour lequel les fonctions sont écrites.
Wildcard
3
@Wildcard j'ai depuis (6 ans) pris cette même habitude. L'extension a beaucoup de sens pour la recherche de bits de script. Par exemple, à partir d'un script exécutable écrit pour zsh (c'est- #!/bin/zshà- dire en haut), vous savez que vous pouvez créer un autre fichier en toute sécurité avec l'extension .zsh et vous assurer qu'il contient le code zsh légal. Si votre script exécutable est strictement conforme à Bourne Shell (c'est- #!/bin/shà- dire tout en haut), vous saurez que la recherche de ce fichier .zsh posera problème.
Dan Moulding
4
Je trouve que l'utilisation de ".sh", ".py", ".pl", etc. est pratique, et certains éditeurs de texte (par exemple, Geany) l'utilisent pour faire une première tentative de définition du schéma de coloration syntaxique approprié.
bgvaughan
7

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.

Gelraen
la source
5
Bien que gelraen soit correct à 100%: Unix / Linux en tant que tel ne s’intéresse pas aux extensions de fichiers, mais les versions modernes de Linux s’intéressent dans la mesure où certaines extensions de shell fournissent une identification spéciale (couleurs ou autres) de certains types de fichiers et les gestionnaires de fichiers fournissent des associations automatiques. avec des programmes. Mais il est tout aussi important que l’utilisateur humain sache quel fichier est quel type. À cette fin, il est pratique de s'en tenir à un système standard non seulement cohérent pour vous-même, mais avec les autres. À cet égard, les choses ne devraient pas être trop différentes de celles de MS Windows (ou MIME).
asoundmove
Cela dit, plusieurs styles d'extension peuvent parfois correspondre au même objectif. Ainsi, .tar.gz est équivalent à .tgz, .tar.bz2 = .tbz, .ps.gz est souvent abrégé en .ps (ce qui prête à confusion) et je suis sûr qu’il en existe beaucoup plus.
asoundmove
@asoundmove .ps.gz signifie que c'est un fichier compressé .ps. Tout comme .tar.gz signifie fichier compressé .tar.
jonescb
1
@ jonescb, oui bien sûr. Mon point à propos de la confusion est que, quand je vois .ps, je m'attends à un fichier non compressé (que je devrais être capable de chat ou moins), mais souvent les fichiers .ps sont compressés et devraient en fait être .ps.gz pour plus de clarté ( car ils nécessitent zcat ou zless pour la visualisation du code source). Certaines personnes ont tout de même décidé de suffixer les fichiers PostScript compressés avec le suffixe. Certains téléspectateurs ps ordinaires ne voient pas d'inconvénient à ce qu'ils soient compressés ou non.
asoundmove
6

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

Roy Truelove
la source
4

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)

Istvan
la source
5
Bien sûr, vous ne pouvez même pas utiliser "/" dans les noms de fichiers. Tout le reste est possible. Et si vous voulez rendre l'accès difficile, même utile ;-)
Jürgen A. Erhard
La liste est en réalité beaucoup plus longue, y compris les caractères de contrôle et les caractères non-ASCII. Oui, vous pouvez avoir un retour arrière dans le nom de fichier * nix.
L0B0
1
Plus précisément, la plupart des systèmes * nix n'autorisent que deux caractères spécifiques dans les noms de fichiers: le /séparateur de chemin et le terminateur de chaîne \ 0 (ASCII zéro).
un CVn
4

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.

...

se déplacer
la source
3

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.

BillThor
la source
5
CamelCase est un anti pattern sur Unix. Le PO posait des questions sur les conventions.
Mikel
2
Ce n'est pas "mauvais" contre "bon". C'est "c'est comme ça que ça se fait d'habitude". C'est une convention que le PO demandait. La raison? C'est peut-être parce que les gens sous Unix n'aiment pas appuyer sur Shift, parce que les anciens systèmes ne disposaient que de MAJUSCULES ou pour une autre raison. Je ne suis pas sûr.
Mikel
@ Mikel Je programme également Java où CamelCase est une convention. Parfois, les modèles et les conventions sont en conflit.
BillThor
.scr est également une extension exécutable Windows.
LawrenceC
1
@ultrasawblade Merci, indique la fréquence à laquelle j'écris Windows. J'ai essayé de passer les extensions exécutables les plus rares telles que cmd, pif, vb *, wsh et le reste.
BillThor
2

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".

bgvaughan
la source
2

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

cat << EOF > foo-bar.sh  
foo_bar() {  
echo baz  
}  
EOF  
Akhil J
la source
0

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.

Johan
la source
0

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.

GMaster
la source
Hmmm, pourquoi lisez-vous vos noms de fichiers dans une police à largeur variable? Ouvrez votre terminal et -et _prendre exactement le même espace! :)
Wildcard
Haha, tu as raison. J'utilise la police patchée SourceCodePro + Powerline + Awesome Regular. Même avec les polices monospaces, l' _apparence est plus nette, même si cela prend le même espace que -. J'aurais dû utiliser le mot "apparemment". En ce qui concerne la _et -lors de l' utilisation des polices Monospace, la différence peut être mieux expliqué avec cette image analogique: evsc.net/v8/wp/wp-content/uploads/2010/09/...
GMaster
-1

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.

Bill Chatfield
la source
-2

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.

Yitzchak
la source
5
-1. CamelCase n'est PAS utilisé sous Linux.
Mikel