Les extensions de fichiers ont-elles une utilité sous Linux ?

Il n'y a pas de réponse 100% noire ou blanche ici.

Habituellement Linux ne se fie pas aux noms de fichiers (et aux extensions de fichiers, c'est-à-dire la partie du nom de fichier après le dernier point habituel) et détermine plutôt le type de fichier en examinant les premiers octets de son contenu et en les comparant à une liste de fichiers connus. chiffres magiques .

Par exemple, tous les fichiers d'image Bitmap (généralement avec l'extension de nom .bmp ) doit commencer par les lettres BM dans leurs deux premiers octets. scripts dans la plupart des langages de script comme Bash, Python, Perl, AWK, etc. (en gros, tout ce qui traite les lignes commençant par # en tant que commentaire) peut contenir un shebang comme #!/bin/bash comme première ligne. Ce commentaire spécial indique au système avec quelle application ouvrir le fichier.

Normalement, le système d'exploitation se base sur le contenu du fichier et non sur son nom pour déterminer le type de fichier, mais affirmer que les extensions de fichier ne sont jamais nécessaires sous Linux n'est que la moitié de la vérité.

Les applications peuvent bien sûr mettre en œuvre leurs contrôles de fichiers comme elles le souhaitent, ce qui inclut la vérification du nom et de l'extension du fichier. Un exemple est l'œil de Gnome ( eog (visionneur d'images standard) qui détermine le format de l'image par l'extension du fichier et génère une erreur s'il ne correspond pas au contenu. La question de savoir s'il s'agit d'un bogue ou d'une fonctionnalité peut être discutée...

Cependant, même certaines parties du système d'exploitation s'appuient sur les extensions de nom de fichier, par exemple lors de l'analyse des fichiers de sources de votre logiciel dans le format /etc/apt/sources.list.d/ - seuls les fichiers avec l'extension *.list sont analysés, tous les autres sont ignorés. Elle n'est peut-être pas principalement utilisée pour déterminer le type de fichier mais plutôt pour activer/désactiver l'analyse de certains fichiers, mais il s'agit toujours d'une extension de fichier qui affecte la façon dont le système traite un fichier.

Et bien sûr, l'utilisateur humain tire le plus grand profit des extensions de fichiers, car elles rendent le type de fichier évident et permettent également de créer plusieurs fichiers avec le même nom de base et des extensions différentes, par exemple site.html , site.php , site.js , site.css etc. L'inconvénient est bien sûr que l'extension du fichier et le type de fichier/contenu réel ne doivent pas nécessairement correspondre.

De plus, il est nécessaire pour l'interopérabilité entre plates-formes, car par exemple, Windows ne saura pas quoi faire avec un fichier readme mais seulement un readme.txt .

J'aimerais adopter une approche différente de celle des autres réponses, et contester l'idée que "Linux" ou "Windows" ont quelque chose à voir avec cela (soyez indulgent avec moi).

Le concept d'une extension de fichier peut être exprimé simplement comme "une convention pour identifier le type d'un fichier sur la base d'une partie de son nom". Les autres conventions courantes pour identifier le type d'un fichier sont la comparaison de son contenu avec une base de données de signatures connues (l'approche du "numéro magique") et son stockage en tant qu'attribut supplémentaire sur le système de fichiers (l'approche utilisée dans le MacOS original).

Étant donné que chaque fichier sur un système Windows ou Linux possède à la fois un nom et un contenu, les processus qui souhaitent connaître le type de fichier peuvent utiliser les approches "extension" ou "numéro magique" comme bon leur semble. L'approche par les métadonnées n'est pas généralement disponible, car il n'existe pas d'emplacement standard pour cet attribut sur la plupart des systèmes de fichiers.

Sous Windows, il existe une forte tradition d'utilisation de l'extension de fichier comme moyen principal d'identification d'un fichier ; de manière plus visible, le navigateur graphique de fichiers (le gestionnaire de fichiers sous Windows 3.1 et l'explorateur sous Windows moderne) l'utilise lorsque vous double-cliquez sur un fichier pour déterminer l'application à lancer. Sur Linux (et, plus généralement, sur les systèmes basés sur Unix), il y a plus de tradition pour inspecter le contenu ; plus particulièrement, le noyau regarde le début d'un fichier exécuté directement pour déterminer comment l'exécuter ; les fichiers script peuvent indiquer un interpréteur à utiliser en commençant par #! suivi du chemin vers l'interpréteur.

Ces traditions influencent la conception de l'interface utilisateur des programmes écrits pour chaque système, mais il existe de nombreuses exceptions, car chaque approche présente des avantages et des inconvénients dans différentes situations. Les raisons d'utiliser les extensions de fichiers plutôt que d'examiner le contenu sont les suivantes :

• l'examen du contenu des fichiers est assez coûteux par rapport à l'examen des noms de fichiers ; ainsi, par exemple, "trouver tous les fichiers nommés *.conf" sera beaucoup plus rapide que "trouver tous les fichiers dont la première ligne correspond à cette signature".
• le contenu des fichiers peut être ambigu ; de nombreux formats de fichiers ne sont en fait que des fichiers texte traités d'une manière particulière, de nombreux autres sont des fichiers zip spécialement structurés, et il peut être délicat de définir des signatures précises pour ces derniers
• un fichier peut véritablement être valide pour plus d'un type ; un fichier HTML peut également être valide pour le format XML, un fichier zip et un GIF concaténés ensemble restent valides pour les deux formats.
• la correspondance des nombres magiques peut entraîner des faux positifs ; un format de fichier sans en-tête peut commencer par les octets "GIF89a" et être identifié à tort comme une image GIF.
• renommer un fichier peut être un moyen pratique de le marquer comme "désactivé" ; par exemple, changer "foo.conf" en "foo.conf~" pour indiquer une sauvegarde est plus facile que d'éditer le fichier pour commenter toutes ses directives, et plus pratique que de le déplacer hors d'un répertoire autoloadé ; de même, renommer un fichier .php en .txt indiquera à Apache de servir sa source en texte brut, plutôt que de la passer au moteur PHP

Exemples de programmes Linux qui utilisent les noms de fichiers par défaut (mais peuvent avoir d'autres modes) :

• gzip et gunzip ont une gestion spéciale de tout fichier se terminant par ".gz".
• gcc traitera les fichiers ".c" comme C, et ".cc" ou ".C" comme C++.

Comme d'autres l'ont mentionné, Linux utilise une méthode de directive d'interprétation (stockage de certaines métadonnées dans un fichier sous la forme d'un en-tête ou d'un numéro magique afin de pouvoir demander à l'interprète approprié de le lire) plutôt que la méthode d'association d'extension de nom de fichier utilisée par Windows.

Cela signifie que vous pouvez créer un fichier avec presque tous les noms que vous voulez... à quelques exceptions près

Cependant

Je voudrais ajouter un mot d'avertissement.

Si vous avez sur votre système des fichiers provenant d'un système qui utilise l'association de noms de fichiers, il se peut que les fichiers n'aient pas ces chiffres magiques ou ces en-têtes. Les extensions de nom de fichier sont utilisées pour identifier ces fichiers par les applications capables de les lire, et vous pouvez rencontrer des effets inattendus si vous renommez ces fichiers. Par exemple :

Si vous renommez un fichier My Novel.doc a My-Novel Libreoffice pourra toujours l'ouvrir, mais il s'ouvrira sous le nom de "Untitled" et vous devrez le renommer pour l'enregistrer (Libreoffice ajoute une extension par défaut, vous aurez donc deux fichiers). My-Novel y My-Novel.odt (ce qui peut être gênant)

Plus sérieusement, si vous renommez un fichier My Spreadsheet.xlsx en My-Spreadsheet, puis essayez de l'ouvrir avec xdg-open My-Spreadsheet vous obtiendrez ceci (car il s'agit en fait d'un fichier compressé) :

Et si vous renommez un fichier My Spreadsheet.xls a My-Spreadsheet quand vous xdg-open My-Spreadsheet vous obtenez une erreur disant

lieu d'ouverture des erreurs : Aucune application n'est enregistrée pour gérer ce fichier

(Bien que dans ces deux cas, cela fonctionne correctement si vous faites soffice My-Spreadsheet )

Si vous renommez ensuite le fichier sans extension en My-Spreadsheet.ods avec mv et essayez de l'ouvrir, vous obtiendrez ceci :

(la réparation échoue)

Et vous devrez remettre l'extension d'origine pour ouvrir le fichier correctement (vous pourrez ensuite convertir le format si vous le souhaitez).

TL;DR :

Si vous avez des fichiers non natifs avec des extensions de nom, ne supprimez pas les extensions en pensant que tout sera OK !

En fait, certaines technologies hacer reposent sur les extensions de fichiers, donc si vous utilisez ces technologies dans Ubuntu, vous devrez également compter sur les extensions. Quelques exemples :

• gcc utilise des extensions pour distinguer les fichiers C et C++. Sans l'extension, il est pratiquement impossible de les différencier (imaginez un fichier C++ sans classes).
• de nombreux fichiers ( docx , jar , apk ) ne sont que des archives ZIP particulièrement structurées. Bien que vous puissiez généralement déduire le type à partir du contenu, ce n'est pas toujours possible (par exemple, Java Manifest est en option sur jar ).

Ne pas utiliser les extensions de fichiers dans de tels cas ne sera possible qu'avec des solutions de fortune et risque d'entraîner de nombreuses erreurs.