Est-il considéré comme une meilleure pratique de ne pas utiliser de majuscules dans la dénomination des fichiers?

28

Les gens disent que vous ne devriez pas utiliser d'espaces dans la dénomination des fichiers Unix. Y a-t-il de bonnes raisons de ne pas utiliser de majuscules dans les noms de fichiers (c.-à-d. File_Name.txtVs file_name.txt)? Ou est-ce simplement une question de préférence personnelle?

filenames

— DD343
source

Vous pouvez utiliser des bouchons, mais ne l'utilisez pas en standard. Utilisez simplement des lettres minuscules et _ donc file_name.txt est bon.

— Shabir A.

9

Il y a des choses Unixy qui utilisent des noms de fichiers avec des majuscules ... quelques exemples incluent le Makefile, INSTALL, CHANGELOG et bien sûr le vénérable README.

— Thomas

PSR-2 - la norme de dénomination de facto du monde PHP, qui s'exécute à la majorité sous Linux utilise camelCase php-fig.org/psr/psr-2

— jdog

46

Les gens disent que vous ne devriez pas espacer les noms de fichiers Unix.

Les gens disent beaucoup de choses. Il existe certains outils qui peuvent bousiller, mais j'espère qu'ils sont peu nombreux à ce stade, car les espaces sont un virus proliféré par des sociétés de systèmes d'exploitation propriétaires géantes et désormais impossible à éviter.

Les espaces rendent difficile la spécification des noms de fichiers sur la ligne de commande, etc. C'est à peu près ça. Les seuls caractères catégoriquement interdits sur les systèmes * nix sont NUL (ne vous inquiétez pas, ce n'est pas sur votre clavier, ni sur ceux de quelqu'un d'autre) et /, puisque c'est le séparateur de chemin. ¹ À part ça, tout est permis. Les éléments de chemin d'accès individuels (noms de fichiers) sont limités à 255 octets (une complication possible si vous utilisez des jeux de caractères étendus) et des chemins complets à 4 Ko.

Ou est-ce juste une question de préférence personnelle

Je dirais que oui. Dans votre plus DE semblent créer de un grand nombre de répertoires capitalisés $HOME( Downloads, Desktop, Documents- le Dest très populaire), donc il n'y a rien de bizarre à ce sujet. Il existe également des fichiers traditionnels très courants contenant des majuscules, tels que .Xclientset .Xauthority.

Une valeur de capitaliser les choses au début est que lorsqu'elles sont répertoriées lexicographiquement, elles passeront avant les choses minuscules - au moins, avec de nombreux outils, et soumises aux paramètres régionaux.

Je suis un fan de camel case (aka. CamelCase) et je l'utilise avec des noms de fichiers, par exemple, peu /home/goldilocks/blueSuedeShoesimporte ce qu'il y a dedans. Certainement une question de préférence personnelle, mais cela ne m'a pas encore causé de chagrin.

Les fichiers de classe Java ont tendance à contenir des majuscules par nature, car les noms de classe Java le font. Et bien sûr, n'oublions pas NetworkManager, même si certains d'entre nous préfèrent.

^{1. Il y a un jeu de caractères beaucoup plus délimité, recommandé par POSIX "Portable Filename Character Set" qui n'inclut pas l'espace - mais il inclut les majuscules! POSIX spécifie également la restriction plus générale concernant "le caractère barre oblique et l'octet nul" ailleurs dans le même document . Cela reflète ou se reflète dans les pratiques conventionnelles de longue date .}

— boucle d'or
source

5

Mia: "Est-ce un fait?" Vincent: "Non ce n'est pas, c'est juste ce que j'ai entendu." Mia: "Qui vous a dit ça?" Vincent: "Ils." Mia: "Ils parlent beaucoup, non?" Vincent: "Certainement."

— corsiKa

4

"La valeur de capitaliser quelque chose au début est que lorsqu'ils sont répertoriés lexicographiquement [...], ils passeront avant tout le reste." - Bien sûr, cela ne fonctionne que si la plupart des noms de fichiers sont en minuscules, ce qui vous donne une raison de réserver des plafonds ( au moins les majuscules) pour vos READMEs et Makefiles et ainsi de suite.

— Blacklight Shining

4

Sur de nombreux claviers, ctrl-espace ou ctrl- @ ou alt-0 tapera un NUL.

— dubiousjim

2

@dodgethesteamroller Je pense que vous vous trompez complètement sur la barre oblique (ou plus précisément, l' octet avec la valeur 0x2F) dans ext *. En fait, je ne pense pas que cela atteindra même le système de fichiers; la couche VFS la désactivera quel que soit le magasin de sauvegarde.

— zwol

3

il suffit de ne pas utiliser d'espaces dans les noms de fichiers et les noms de répertoires. même si votre système le permet techniquement, cela ne fera que vous causer du chagrin. Utilisez plutôt "_" le caractère de soulignement.

— SnakeDoc

9

Une raison d'éviter les majuscules dans les noms de fichiers est que l'ordre de tri dans Unix est sensible à la casse, donc les fichiers commençant par une majuscule apparaîtront dans le désordre. C'est la raison pour laquelle Makefileest généralement nommé en utilisant une majuscule M- c'est l'un des fichiers que vous souhaitez voir en premier, sans faire défiler / sauter vers le bas a-l.

Cela dit, vous pouvez faire bien pire en termes de noms de fichiers:

l'utilisation d'espaces cassera certains programmes et scripts mal écrits qui ne citent pas correctement les noms de fichiers
le démarrage d'un nom de fichier avec un -peut provoquer des problèmes car de nombreux programmes le verront comme une option de ligne de commande au lieu d'un nom de fichier (par exemple rm -r, ne supprimera pas un fichier nommé -r).
le démarrage d'un nom de fichier avec un .le masquera à de nombreux utilitaires et à la globalisation du shell (par exemple rm *, ne supprimera pas les fichiers comme .config)
l'utilisation de caractères spéciaux comme |<>*?et même de caractères non imprimables comme newlineest techniquement possible, mais peut casser des scripts / programmes similaires au caractère espace. La différence est que le caractère espace est souvent utilisé, donc les programmeurs ont tendance à tester leurs programmes par rapport à lui, tandis que les caractères moins populaires restent souvent non testés.

— Dmitry Grigoryev
source

4

Cela a tendance à ne plus être vrai, le tri dans les environnements locaux modernes a tendance à être insensible à la casse de nos jours et de nombreux outils et globes de shell respectent l'environnement local pour le tri des noms de fichiers.

— Stéphane Chazelas

2

Vouliez-vous dire: rm *ne supprimera pas les fichiers comme .config?

— Wildcard

1

@Wildcard pas vraiment, mais peut-être que votre exemple est plus réaliste que le mien. Mon but était de montrer que les noms de fichiers commençant par un point sont immunisés contre la globalisation même si l'utilisateur spécifie explicitement ce point.

— Dmitry Grigoryev,

1

@DmitryGrigoryev, non, ils ne le sont pas. Essayez ls -ald. ?? * dans n'importe quel répertoire contenant des fichiers dot.

— Bill Barth

1

Je pense qu'il serait plus approprié de dire "Si vous choisissez d'utiliser des majuscules dans les noms de fichiers, vous devez garder à l'esprit le fait que l'ordre de tri sous Unix est (parfois) sensible à la casse." L'utilisateur peut vouloir ce comportement Makefileet en READMEest un parfait exemple. Notez également que cet effet est négligeable si la lettre n'est pas la première lettre du nom, donc ce n'est pas grave si vous utilisez camelCase. Bien sûr, vous pourriez être surpris de voir anOctagonavant angle, mais au moins, ils seraient ensemble dans la liste.

— G-Man dit `` Réintègre Monica ''

6

Si vous allez vous interfacer avec un environnement Windows, vous devez éviter les majuscules car Windows mettra tout en minuscules. C'est plus souvent un problème qui va dans l'autre sens; un lien vers Page_2.htmlsera trouvé page_2.htmldans Windows, mais échouera sous Unix.

— NL_Derek
source

10

Ce n'est pas vrai. NTFS, VFAT et exFAT sont tous insensibles à la casse mais préservant la casse, ce qui signifie qu'ils ignorent la casse à des fins de recherche, mais stockent néanmoins la casse. Il en va de même pour HFS +, le système de fichiers par défaut sous OSX. NTFS a même un espace de noms POSIX qui fonctionne exactement comme tous les autres Unices, c'est-à-dire des noms de fichiers très longs d'octets non interprétés, avec seulement NULet /interdits.

— Jörg W Mittag du

5

Plus précisément, "insensible à la casse mais respectant la casse" est une autre façon de dire "capable d'écraser silencieusement le fichier A car son nom ne diffère qu'en cas de fichier B" (ou vice versa, selon celui qui a été enregistré ultérieurement). En d'autres termes, si vous utilisez un shell * nix pour accéder à un partage NTFS, cat > Foole fichier sera écrasé foo. Ce comportement est susceptible d'être inattendu et déroutant si vous êtes habitué à la préservation de cas et les systèmes de fichiers sensibles à la casse tels que poste *.

— dodgethesteamroller

1

@ JörgWMittag Sauf erreur, NTFS n'est pas insensible à la casse, c'est juste que Windows fonctionne de façon mystérieuse.

— Cthulhu

1

@Cthulhu: AFAIK, NTFS a quatre espaces de noms différents dans lesquels vous pouvez créer des noms pour les fichiers. (Je ne sais pas si un seul fichier peut avoir un nom dans plus d'un espace de noms.) Un espace de noms "DOS" (8.3, insensible à la casse), un espace de noms "long" (insensible à la casse, préservant la casse, UTF-16), un espace de noms spécial pour les noms "courts longs", c'est-à-dire les noms dont la casse doit être conservée mais qui tiennent en 8.3, et un espace de noms POSIX (un flux d'octets autres que \0et /, respectant la casse). C'est du moins ainsi que je m'en souviens. Mais je suis d'accord que c'est un peu le bordel. Il y a d'autres restrictions dans le…

— Jörg W Mittag

1

... noyau, et même d'autres restrictions dans l'API (en fait, il existe différentes API de différentes époques avec différentes restrictions), il y a des restrictions en raison de la compatibilité avec DOS et FAT, il y a des restrictions dans l'interpréteur de commandes, il y a des restrictions dans le ( graphique), et il existe des restrictions dans l'Explorateur. Et il est souvent impossible de déterminer de manière fiable d' où vient une restriction. C'est fou. Une fois, j'ai réussi à créer un fichier à l'aide de l'explorateur , qui ne pouvait pas être ouvert, copié, déplacé, renommé ou supprimé à l'aide de n'importe quel outil que j'ai essayé. Il est resté essentiellement…

— Jörg W Mittag

4

Une raison pour éviter les majuscules est que la bashcomplétion de tabulation est sensible à la casse (au moins par défaut) - cela me fait toujours trébucher à chaque fois que je me retrouve devant une bashconfiguration par défaut. Bien sûr, il existe d'autres shells populaires, mais cela combiné au fait qu'il bashs'agit du shell de connexion par défaut sur de nombreux systèmes d'exploitation signifie que la valeur par défaut est souvent sensible à la casse. L'utilisation de noms de fichiers en minuscules simplifie plutôt les choses ici.

— Blacklight Shining
source

2

echo set completion-ignore-case On >> ~/.inputrcpeut aider un peu, au moins sur votre propre système.

— wchargin

1

Je ne sais pas quel est le but de cette réponse - à moins que vous ne puissiez oublier comment vous "épelez" un nom de fichier. Par exemple, si vous créez un fichier nommé Fooet de type ultérieur cat f(Tab), il échouera. Mais la même chose se produit si vous tapez cat foo, cat Foobarou cat Fu- le fait que vous aurez du mal à accéder à un fichier dont vous ne vous souvenez pas correctement n'a vraiment rien à voir avec la saisie semi-automatique.

— G-Man dit `` Réintègre Monica ''

@ G-Man Touché. Pourtant, l'utilisation de noms de fichiers en minuscules signifie que vous avez une chose de moins à retenir à leur sujet.

— Blacklight Shining

3

Depuis que NL_Derek a ouvert cette boîte de vers, mais ne l'a pas articulée correctement, je dirai ceci:

Vous pouvez utiliser des majuscules, mais vous devez éviter de créer des fichiers (dans le même répertoire) qui ne diffèrent que par la casse , par exemple, File_Name.txt et file_name.txt , car

Si vous rendez le répertoire accessible à un système Windows, il ne pourra pas accéder aux deux fichiers. Il ne pourra probablement accéder qu'à celui qui apparaît en premier dans le répertoire, quel que soit le nom que vous utilisez. (Sauf: il peut vous donner accès à eux en tant que FILENA~1.TXTet FILENA~2.TXT - type dir /xpour voir quel nom court (le cas échéant) va avec quel nom long.)
Si le système de fichiers est en fait un système de fichiers Windows (par exemple, monté à partir d'un système de fichiers exFAT ou NTFS à partir d'un serveur NFS exécutant Windows), les deux noms ne seront (probablement) pas autorisés à coexister. Par exemple, si vous faites et , vous pouvez vous retrouver avec un seul fichier, contenant la sortie de .cmd₁ > foocmd₂ > Foocmd₂
De même, si jamais vous transférez les fichiers vers un système Windows, les deux noms ne seront (probablement) pas autorisés à coexister. Par exemple, si vous avez créé une archive (par exemple, zip) contenant les deux fichiers et que vous l'avez extraite sur un système Windows, le deuxième fichier écraserait probablement le premier. Même chose si vous les avez transférés vers une boîte Windows avec FTP ou quelque chose de similaire.

— G-Man dit «Réintègre Monica»
source

Non seulement Windows, mais plusieurs autres OS (VMS, je pense, CP / M certainement, d'autres ...)

— Toby Speight

3

Outre des raisons techniques, j'ai un aspect pratique à cela. Respecter les lettres minuscules garantira que les recherches seront plus faciles à moins que l'on aime trop utiliser grep -i ou localiser -i. Parfois, même camelCase peut être déroutant si l'on doit utiliser une chaîne de mots similaires comme dans storageNYCDCPrimary. Donc, je trouve préférable de s'en tenir aux minuscules et de les poivrer avec des traits de soulignement ou des tirets pour la lisibilité, comme storage_nyc_dc_primary.

— Hopping Bunny
source

snake_case est agréable pour les yeux - storageNycDcPrimaryet StorageNycDcPrimarysont tous deux étranges à lire.

— go2null

1

Je considère qu'il est préférable d' éviter d'utiliser des majuscules et des espaces dans les noms de fichiers.

Certains diront qu'ils ne sont pas d'accord mais c'est une question ou ce que j'appelle des croyances religieuses : difficile de discuter et de s'entendre. Ceux qui ne sont pas d'accord disent que la plupart des outils sont désormais fixés pour être adaptés aux capitales et aux espaces: ils ont raison, mais ce n'est pas la question.

La bonne question est de savoir de combien avez-vous besoin pour utiliser les majuscules et les espaces dans les noms de fichiers. À cette question, sauf lorsque je programme en Java, la réponse est la plupart du temps: je n'ai pas besoin de majuscules et d'espaces dans mes noms de fichiers . Tous les espaces que je remplace par un trait de soulignement ( _) ou un signe moins ( -), et pour cette raison, je n'utilise pas d'étui à chameau (aka. CamelCase) contrairement à certaines autres religions.

Beaucoup de gens m'ont appelé des conneries pour avoir fait et enseigné que - certains le font toujours - certains ont trébuché sur un outil qui n'était pas favorable aux capitaux / à l'espace et sont venus me dire que j'avais raison et qu'ils auraient dû m'écouter. Faites ce que vous voulez , et si vous utilisez des majuscules et des espaces dans le nom de fichier, j'espère que vous ne trébucherez jamais sur un outil mal écrit. Cependant, si vous voyagez avec un tel outil, je l'espère, ce ne sera pas difficile à réparer et cela ne coûtera pas à votre entreprise et / ou à vous beaucoup d'argent et / ou de temps. Mais si cela finit par avoir de mauvaises répercussions, vous vous souviendrez que certains vous ont dit dans le passé que l'utilisation de majuscules et d'espaces dans les noms de fichiers était une mauvaise pratique.

Et une dernière chose, si vous voulez éviter tous les problèmes , pas de caractères spéciaux dans les noms de fichiers (uniquement les lettres minuscules, les chiffres, le soulignement et les inconvénients [1]). Cette liste de caractères indésirables comprend également tous les caractères non ascii (oui, français et autres non anglais - et je suis l'un d'eux - aucun d'entre eux: à, â, ä, ç, é, ..., ö, æ, œ , ...). Cela s'étend également à de nombreuses autres choses, y compris le login et le mot de passe . Je vous laisse deviner ce qui se passe lorsque vous mettez un devis ou un guillemet double ( 'ou ") dans un identifiant ou un mot de passe géré par un script bash non écrit par un administrateur système confirmé ....

[1]: peut - être que nous pourrions étendre cela à ~, @, #et quelques autres, mais cela est à la recherche des ennuis (et oui je sais sur les fichiers emacs ...).

— jfg956
source

1

La dernière chose est quelque chose qui devrait être géré par le système d'authentification, pas par l'utilisateur qui fournit le mot de passe. Si le système limite l'ensemble des caractères autorisés dans les mots de passe, c'est un mauvais système.

— Blacklight Shining

Eh bien, limiter les caractères dans le mot de passe est un sujet de débat: li1, oO0, ... selon les amateurs, difficile à communiquer. Certains diraient que le mot de passe ne doit pas être communiqué, mais une clé WiFi est une sorte de mot de passe que je communique à mes amis lorsqu'ils sont chez moi ...

— jfg956

C'est un choix conscient de votre part pour éviter d'utiliser certains caractères, plutôt qu'une limitation intégrée au système (dans cet exemple, les normes Wi-Fi, les implémentations AP et client, etc.). Si vous utilisez une chaîne de caractères sélectionnés au hasard comme mot de passe, vous pouvez améliorer la lisibilité en utilisant (ou en encourageant les destinataires à utiliser) une police à espacement fixe, ou en utilisant simplement des glyphes plus distinctifs si vous les écrivez à la main (en minuscules seriffés L, I majuscule et chiffre 1; O minuscule plus petit, O majuscule arrondi, chiffre 0 barré ou en pointillé; etc.). Vous pouvez également utiliser une phrase secrète.

— Blacklight Shining