Question Les extensions de fichiers ont-elles une utilité (pour le système d'exploitation)?


Linux détermine le type d'un fichier via un code dans l'en-tête du fichier. Cela ne dépend pas des extensions de fichiers pour savoir quel logiciel utiliser pour ouvrir le fichier.

C'est ce que je me souviens de mon éducation. S'il vous plaît corrigez-moi au cas où je me trompe!

Travailler un peu avec les systèmes Ubuntu récemment: je vois beaucoup de fichiers sur les systèmes qui ont des extensions comme .sh, .txt, .o, .c

Maintenant, je me demande: ces extensions sont-elles destinées uniquement aux humains? Pour que l'on puisse avoir une idée du type de fichier qu'il contient?

Ou ont-ils un but pour le système d'exploitation aussi?


66
2017-07-27 06:46


origine


Si vous n'obtenez pas une bonne réponse ici, rappelez-vous qu'il y a aussi unix.stackexchange.com - mchid
@ Merci beaucoup. C'est très gentil de votre part. - mizech
En rapport, presque en double: askubuntu.com/questions/390015/… - Zzzach...
Sous Windows, sous Linux / Unix, ils le font la plupart non. Les principales exceptions sont les programmes de compression - gzip, bzip2, xz - etc. Ces programmes utilisent des suffixes pour séparer la version compressée d'un fichier de la version non compressée qu'ils remplacent. Les programmes de compression se plaignent souvent d'un suffixe incorrect, même si le fichier est en réalité un fichier compressé du type qu'il doit gérer. - Baard Kopperud
Je pense qu'une partie du problème avec cette question est que "le système d'exploitation" n'est pas un concept bien défini. Qu'est-ce qui fait partie du système d'exploitation et qu'est-ce qu'une application en plus? Peu de parties du système d’exploitation (quel que soit l’OS dont nous parlons) se soucient du type de fichier - elles ne font que ce qu’elles ont dit. Donc, des distinctions à propos de Comment ils savent qu'ils ne sont pas pertinents; ils ne font ni l'un ni l'autre. Les applcations, par contre, pourraient bien faire une ou deux choses. - IMSoP


Réponses:


Linux détermine le type d'un fichier via un code dans l'en-tête du fichier. Cela ne dépend pas des extensions de fichiers à connaître avec le logiciel à utiliser pour ouvrir le fichier.

C'est ce que je me souviens de mon éducation. S'il vous plaît corrigez-moi au cas où je me trompe!

  • correctement rappelé.

Ces extensions sont-elles destinées uniquement aux humains?

  • Oui, avec un mais.

Lorsque vous interagissez avec d'autres systèmes d'exploitation qui dépendent de ce que les extensions sont ce qu'elles sont, il est plus judicieux de les utiliser.

Sous Windows, l'ouverture du logiciel est associée aux extensions.

Ouvrir un fichier texte nommé "fichier" est plus difficile sous Windows que d’ouvrir le même fichier nommé "fichier.txt" (vous devrez changer le dialogue d’ouverture du fichier à partir de *.txt à *.* à chaque fois). Il en va de même pour les fichiers texte séparés par des tabulations et des points-virgules. Il en va de même pour l'importation et l'exportation de courriers électroniques (extension .mbox).

En particulier lorsque vous codez un logiciel. Ouvrir un fichier nommé "software1", qui est un fichier HTML et "software2", qui est un fichier JavaScript, devient plus difficile que "software.html" et "software.js".


S'il existe un système sous Linux où les extensions de fichiers sont importantes, j'appellerais cela un bogue. Lorsque le logiciel dépend d'extensions de fichiers, c'est exploitable. Nous utilisons un directive interprète pour identifier ce qu'est un fichier ("les deux premiers octets dans un fichier peuvent être les caractères" #! ", qui constituent un nombre magique (hexadécimal 23 et 21, les valeurs ASCII de" # "et"! ") comme shebang, ").

Le problème le plus célèbre avec les extensions de fichiers était LOVE-LETTER-FOR-YOU.TXT.vbs sur Windows Ceci est un script visuel de base affiché dans l'explorateur de fichiers sous forme de fichier texte.

Dans Ubuntu, lorsque vous démarrez un fichier à partir de Nautilus, vous recevez un message d’avertissement. Exécuter un script à partir de Nautilus où il veut démarrer un logiciel où il est censé ouvrir gEdit est un problème évident et nous en avons un avertissement.

En ligne de commande, lorsque vous exécutez quelque chose, vous pouvez voir visuellement l’extension. Si elle se termine sur .vbs, je commencerais à devenir suspect (pas que .vbs soit exécutable sous Linux, du moins pas sans plus d’efforts;)).


37
2017-07-27 07:01



Je ne comprends absolument pas ce que tu voulais dire dans ta dernière phrase. Tout d'abord, il est difficile de cacher l'extension plutôt que de l'avoir, ensuite l'exploit fonctionnera de la même façon sous Linux - vous nommez un fichier binaire readme.txt et le rendre exécutable. Si l'utilisateur l'exécute, il n'ouvre pas l'éditeur, mais exécute le code. À cet égard, rendre les extensions plus importantes (mais ne pas les cacher) est plus sûr et plus facile à expliquer pour les utilisateurs non avertis. Il existe d'autres différences (notamment ne pas exécuter les fichiers du répertoire actuel), mais elles n'ont rien à voir avec les extensions. - techraf
@techraf En fait, le gestionnaire de fichiers va probablement essayer d'ouvrir le readme.txt fichier avec un éditeur de texte. Je viens d’essayer avec dauphin dans KDE, en créant un script shell en ajoutant une autorisation exécutable, .txt et en cliquant dessus, il sera ouvert dans Kate. Si je le renommer en .sh puis en cliquant dessus le lance. - Bakuriu
linux: comme make est construit autour de règles qui dépendent de l'extension du fichier, cela ne rendrait-il pas (sans jeu de mots) les extensions destinées à plus que des humains? - bolov
C'est une réponse monumentalement fausse. Certaines parties de Linux utilisent des nombres magiques pour déterminer les types de fichiers. Exécuter des fichiers sur la ligne de commande. Mais d'autres parties énormes du système utilisent des extensions de fichiers pour savoir quoi regarder, que ce soit l'éditeur de liens dynamique (qui veut des fichiers .so), modprobe, systèmes de compilation, plugins, bibliothèques pour python, ruby, etc. t avoir des nombres magiques, file est basé sur l'heuristique, pas défini. - Alan Shutko
"Linux détermine le type d'un fichier via un code dans l'en-tête du fichier" "correct" WTF? Quel "code dans l'en-tête du fichier"? Il n'y a pas un tel code, et il n'y a pas un tel "en-tête de fichier" générique sous Linux. - leonbloy


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

habituellement Linux ne s'appuie pas sur les noms de fichiers (et les extensions de fichier, c'est-à-dire la partie du nom de fichier après la dernière période) et détermine le type de fichier en examinant les premiers octets de son contenu et en le comparant à une liste de fichiers connus. chiffres magiques.

Par exemple, tous les fichiers image Bitmap (généralement avec une 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. (essentiellement tout ce qui traite les lignes commençant par # comme commentaire) peut contenir un shebang comme #!/bin/bash en première ligne. Ce commentaire spécial indique au système avec quelle application ouvrir le fichier.

Donc, normalement, le système d'exploitation s'appuie sur le contenu du fichier et non sur son nom pour déterminer le type de fichier, mais déclarer que les extensions de fichier ne sont jamais nécessaires sous Linux ne représente que la moitié de la vérité.


Les applications peuvent bien entendu implémenter leurs vérifications de fichiers comme elles le souhaitent, ce qui inclut la vérification du nom du fichier et de l’extension. Un exemple est l'oeil de gnome (eog, visualiseur d'images standard) qui détermine le format de l'image par l'extension de fichier et génère une erreur si elle ne correspond pas au contenu. Que ce soit un bug ou une fonctionnalité peut être discuté ...

Cependant, même certaines parties du système d'exploitation reposent sur des extensions de nom de fichier, par ex. lors de l'analyse des fichiers de vos sources logicielles dans /etc/apt/sources.list.d/ - uniquement les fichiers avec le *.list extension obtenir analysé tous les autres sont ignorés. Ce n'est peut-être pas principalement utilisé pour déterminer le type de fichier ici, mais plutôt pour activer / désactiver l'analyse de certains fichiers, mais c'est toujours une extension de fichier qui affecte la façon dont le système traite un fichier.

Et bien sûr, l’utilisateur humain profite le plus des extensions de fichiers car cela rend le type de fichier évident et permet également plusieurs fichiers avec le même nom de base et différentes extensions comme site.html, site.php, site.js, site.css L'inconvénient est bien sûr que l'extension de fichier et le type / contenu du fichier ne doivent pas nécessairement correspondre.

De plus, il est nécessaire pour une interopérabilité inter-plate-forme, comme par exemple Windows ne saura pas quoi faire avec un readme fichier, mais seulement un readme.txt.


64
2017-07-27 07:22



Vous vous contredisez légèrement ici: si le visualiseur d'images standard nécessite une terminaison de nom de fichier .bmp, quelle partie du système d'exploitation vous dites dépend du contenu du fichier commençant par "BM"? AFAIK, les seuls "nombres magiques dont le noyau a besoin sont des types exécutables, y compris le cas particulier de #!. Tout le reste est à la décision de certaines applications. - IMSoP
@IMSoP Je ne connais pas la mise en œuvre exacte de eog et je ne sais pas pourquoi ils se soucient du nom de fichier du tout. C'est un bug à mon avis. Et bien sûr, si le fichier s'appelle "bmp" mais que son format de contenu ne correspond pas, il y aura bien sûr une erreur. Bien entendu, chaque application décide comment vérifier les fichiers, mais en général, les applications Linux ne doivent pas se fier au nom. Btw, vous pouvez utiliser le file recommander d'examiner les types de fichiers par leur contenu. - Byte Commander
La phrase que je défie est la suivante: "Linux ... détermine le type de fichier en examinant les premiers octets". Quelle définition de "Linux" utilisez-vous dans cette phrase? L'existence du file l'utilité ne prouve rien vraiment; c'est un outil utile, qui pourrait exister sur n'importe quel système d'exploitation. Quelle partie fondamentale du système d'exploitation rend la course file plus "correct" que le nom du fichier? - IMSoP
Notez que les fichiers sans extension pouvez être associé à un programme. - isanae


Comme mentionné par d’autres, sous Linux, une méthode de directive d’interpréteur est utilisée (stocker certaines métadonnées dans un fichier en tant qu’en-tête ou chiffre magique pour que l’interprète correct puisse le lire) plutôt que la méthode d’association d’extension utilisée par Windows.

Cela signifie que vous pouvez créer un fichier avec presque n'importe quel nom que vous aimez ... à quelques exceptions près

toutefois

Je voudrais ajouter un mot de prudence.

Si vous avez des fichiers sur votre système à partir d'un système qui utilise l'association de noms de fichiers, les fichiers peuvent ne pas avoir ces nombres magiques ou 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 à My-Novel, Libreoffice sera toujours en mesure de l’ouvrir, mais il s’ouvrira sous le nom «Untitled» et vous devrez le nommer à nouveau pour le sauvegarder (Libreoffice ajoute une extension par défaut, vous aurez donc deux fichiers My-Novel et My-Novel.odt, ce qui pourrait être agaçant)

Plus sérieusement, si vous renommez un fichier My Spreadsheet.xlsx en My-Spreadsheet, essayez de l’ouvrir avec xdg-open My-Spreadsheetvous obtiendrez ceci (parce que c'est en fait un fichier compressé):

Et si vous renommez un fichier My Spreadsheet.xls à My-Spreadsheet, lorsque vous xdg-open My-Spreadsheet vous obtenez une erreur en disant

emplacement d'ouverture d'erreur: aucune application n'est enregistrée en tant que traitement de ce fichier

(Bien que dans ces deux cas cela fonctionne bien si vous le 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:

(réparation échoue)

Et vous devrez remettre l'extension originale pour ouvrir le fichier correctement (vous pouvez 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 supposant que tout ira bien!


23
2017-07-27 08:06



Un nouveau document MS Office (docx, xlsx, pptx, etc.) sans extension de fichier s'ouvre dans le gestionnaire d'archive car ces types de fichiers ne sont en réalité que des fichiers compressés ZIP contenant tous les documents XML et fichiers multimédia nécessaires pour définir le contenu du document. Le format de fichier d'un répertoire compressé ZIP est assez courant aujourd'hui. - Byte Commander
Déjà beaucoup de bonnes réponses, mais juste une autre plus spécifique à la libreoffice que j'ai remarquée. Vous créez un fichier de valeurs séparées par des virgules (CSV) et enregistrez-le sous "test.csv", une fenêtre s'ouvrira vous demandant quel type de séparateur utilisez-vous (c'est-à-dire libreoffice Calc). Si vous renommez ce fichier en "test.cs", par exemple, Writer de libreoffice l'ouvre. Ainsi, outre l'exemple ZIP ci-dessus, il semble que libreoffice utilise l'extension de fichier. - Ray
Le système de fichiers linux ne fait rien concernant les types de fichiers. Tout cela dépend des programmes qui s’exécutent dessus. - Peter Green
@ PeterGreen Oui, mais le fait que les programmes lui attribuent une signification signifie que ce n'est pas "juste pour les humains", par exemple, les MacOS classiques le possédaient [il y avait des champs "type de fichier" et "app créateur" de quatre octets t partie du nom du fichier, de sorte que le système d’exploitation et les applications disposent de toutes les informations nécessaires sans examiner les extensions de fichiers] - Random832
@ PeterGreen Le système de fichiers Windows ne fait rien non plus concernant les types de fichiers. Le shell graphique (Windows Explorer) utilise une extension de fichier pour choisir une action pour un double-clic, mais techniquement, ce n'est qu'un programme qui s'exécute au-dessus du système d'exploitation, tout comme Nautilus. Il serait parfaitement possible d'écrire un gestionnaire de fichiers Linux avec ce comportement, ou un gestionnaire Windows qui examinait le contenu du fichier. - IMSoP


Je voudrais adopter une approche différente de celle des autres réponses et remettre en question la notion selon laquelle "Linux" ou "Windows" ont quelque chose à voir avec cela (supporter avec moi).

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

Étant donné que chaque fichier sur un système Windows ou Linux a à la fois un nom et un contenu, les processus qui souhaitent connaître le type de fichier peuvent utiliser les approches "extension" ou "nombre magique" comme ils l'entendent. L'approche par métadonnées n'est généralement pas disponible, car il n'y a pas de place 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 principal moyen d'identification d'un fichier. le plus visiblement, le navigateur de fichiers graphique (Gestionnaire de fichiers sur Windows 3.1 et Explorer sur 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 Unix), l'inspection du contenu est plus traditionnelle. Plus particulièrement, le noyau regarde le début d'un fichier exécuté directement pour déterminer comment l'exécuter. les fichiers de script peuvent indiquer un interpréteur à utiliser en commençant par #! suivi du chemin de l'interprète.

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 les contenus incluent:

  • examiner le contenu des fichiers est assez coûteux par rapport à l'examen des noms de fichiers; 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 du fichier peut être ambigu; de nombreux formats de fichiers ne sont en fait que des fichiers texte traités de manière spéciale, de nombreux autres fichiers zip spécialement structurés, et la définition de signatures précises pour ces fichiers peut être délicate
  • un fichier peut être réellement valide en tant que plusieurs types; un fichier HTML peut également être valide en XML, un fichier zip et un fichier GIF concaténé restent ensemble pour les deux formats
  • la correspondance des nombres magiques peut conduire à 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 qu'une sauvegarde est plus facile que l'édition du fichier pour commenter toutes ses directives, et plus pratique que de le sortir d'un répertoire chargé automatiquement; de même, renommer un fichier .php en .txt indiquera à Apache de servir sa source en texte brut, plutôt que de le transmettre au moteur PHP.

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

  • gzip et gunzip ont un traitement spécial de toute fin de fichier ".gz"
  • gcc va gérer les fichiers ".c" en C, et ".cc" ou ".C" en C ++

19
2017-07-27 17:13



Windows a également une forte tradition de masquer l’extension si elle est "connue" et même DOS a autorisé une commande à omettre .COM, .BAT et .EXE, recherchant automatiquement ceux qui déterminent le programme à exécuter. Il n'y a pas une telle tradition dans * nix. - Monty Harder
Cela devrait être la réponse acceptée. - Ave
C’est une bien meilleure réponse mais une erreur de fait… un script ne peut pas être rendu exécutable en plaçant #! au début. Tout fichier avec son ou ses bits exécutables peut être exécuté de plusieurs manières. #!/bin/bash et des signatures similaires indiquent simplement quel interpréteur utiliser. Si aucune signature n'est fournie, l'interpréteur de shell par défaut est utilisé. Un fichier ne contenant que les deux mots "Hello World", mais avec son bit d'exécution défini, tentera de trouver une commande "Hello" lors de son exécution. - DocSalvager
@DocSalvager Bonne prise, c'était une formulation maladroite autant que n'importe quoi. J'ai reformulé un peu pour préciser que le shebang ne faire le script exécutable, il change juste Comment il est exécuté. - IMSoP


En fait, certaines technologies faire Comptez sur les extensions de fichiers, donc si vous utilisez ces technologies dans Ubuntu, vous devrez également vous fier aux extensions. Quelques exemples:

  • gcc utilise des extensions pour distinguer les fichiers C an C ++. Sans l'extension, il est pratiquement impossible de les différencier (imaginez un fichier C ++ sans classes).
  • beaucoup de 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 du contenu, cela peut ne pas être toujours possible (par exemple, le manifeste Java est optionnel dans jar des dossiers).

Ne pas utiliser les extensions de fichiers dans de tels cas ne sera possible qu'avec des solutions de contournement et sera probablement très sujet aux erreurs.


14
2017-07-27 15:52



C'est bien pour vous d'avoir mentionné la programmation, mais vous avez mal compris la plupart des détails. gcc est le front-end pour les fichiers C, pour les fichiers C ++, vous avez besoin soit du g++ front-end ou un commutateur de ligne de commande pour spécifier la langue. Plus important est le make programme qui décide d'utiliser ou non gcc ou g++ pour construire un fichier particulier - et make est complètement dépendant des modèles de nom de fichier (principalement des extensions) pour sa correspondance de règles. - Ben Voigt
@BenVoigt Lors de la compilation d'un fichier avec un .cc extension avec gcc, il sera vraiment compilé en C ++, et ceci est documenté dans man gcc: "Pour un fichier d'entrée donné, le suffixe du nom de fichier détermine le type de compilation effectuée: suivi d'une liste d'extensions et de leur traitement. - hvd
@hvd C'est peut-être le jeu de bibliothèques par défaut qui tourne mal si vous n'utilisez pas le bon frontal. Quoi qu’il en soit, make est le meilleur exemple car tout ce qu’il fait est basé sur l’extension de fichier. - Ben Voigt
@BenVoigt make est aussi un bon exemple, mais gcc repose autant sur les noms de fichiers. Voici un exemple plus clair que .c contre .cc: Pour C, gcc utilise des suffixes pour savoir si sa première étape est de prétraiter (.c), compiler (.i), assembler (.s), ou lien (.o). Ici, j'utilise -E, -S et -c dire gcc où Arrêtez, mais il utilise des noms de fichiers pour savoir où début.  gcc something.cc ne liera pas les bonnes bibliothèques pour C ++ mais volonté traiter le fichier comme C ++, ce qui explique pourquoi de nombreux utilisateurs sont déconcertés par les messages d’erreur qu’ils reçoivent lorsqu’ils font cette erreur. - Eliah Kagan


Votre première hypothèse est correcte: les extensions sur Linux n’ont pas d’importance et ne sont utiles que pour les humains (et les autres systèmes d’exploitation non-Unix qui se soucient des extensions). Le type d'un fichier est déterminé par les 32 premiers bits de données du fichier, appelé nombre magique C'est pourquoi les scripts shell ont besoin #! line - pour indiquer au système d'exploitation quel interpréteur appeler. Sans elle, le script shell n'est qu'un fichier texte.

En ce qui concerne les gestionnaires de fichiers, ils veulent connaître les extensions de certains fichiers, telles que .desktop fichiers, qui sont fondamentalement les mêmes que la version de Windows des raccourcis, mais avec plus de fonctionnalités. Mais en ce qui concerne l'OS, il doit savoir ce qu'il y a dans le fichier, pas ce qu'il contient


7
2017-07-27 07:02



Ce n'est pas tout à fait vrai. Il existe des programmes qui attendent une extension spécifique. L’exemple le plus couramment utilisé est probablement gunzip qui ne décompresse pas un fichier s'il n'est pas appelé foo.gz. - terdon♦
C'est une implémentation de logiciels spécifiques. Dans la plupart des cas, les utilitaires sur les systèmes de type Unix n'attendent pas d'extension. - Sergiy Kolodyazhnyy
Pour la plupartils ne le font pas, non. Votre première phrase, cependant, affirme qu'ils ne sont jamais utilisés et ne concernent que les humains. Ce n'est pas tout à fait vrai. gunzip est un exemple, eog est un autre. En outre, de nombreux outils ne seront pas automatiquement complétés sans la bonne extension. Tout ce que je dis, c'est que c'est un peu plus compliqué que "les extensions ne sont jamais pertinentes". - terdon♦
1 petit problème: OP interrogé sur le système d'exploitation. 'gunzip' et 'eog' ne sont pas le système d'exploitation mais ont décidé de créer leurs propres restrictions (en cas de gunzip) ou de méthode (eog). "types de mime" cependant. - Rinzwind
@Serg Bien sûr, vous pouvez définir le système d'exploitation de manière étroite et obtenir une réponse triviale à la question. Ce n'est pas une réponse particulièrement utile, car la grande majorité de ce que fait un utilisateur avec un ordinateur implique des logiciels que vous avez exclus. Notez que la question contrastait "seulement pour les humains" contre "le système d'exploitation"; Je ne pense pas qu'ils aient voulu dire "le noyau". - IMSoP


C'est trop gros pour une réponse à un commentaire.

Gardez à l'esprit que même "extension" a beaucoup de sens si différents.

Ce dont vous parlez semble être les 3 lettres après le. DOS a rendu le format 8.3 très populaire et Windows utilise la partie 0.3 à ce jour.

Linux a beaucoup de fichiers comme .conf ou .list ou .d ou .c qui ont un sens, mais ne sont pas vraiment des extensions au sens 8.3. Par exemple, Apache examine /etc/apache2/sites-enabled/website.conf pour sa directive de configuration. Alors que le système utilise les types MIME et les en-têtes de contenu et que ce qu'il ne faut pas déterminer, c'est un fichier texte, Apache (par défaut) ne va toujours pas le charger sans se terminer par .conf.

.c est un autre excellent. Oui, c'est un fichier texte, mais gcc dépend de main.c devenant main.o et enfin main (après la liaison). A aucun moment, le système n'utilise l'extension .c, .o ou no pour avoir un sens en ce qui concerne le contenu, mais ce qui suit. a un sens. Vous devrez probablement configurer votre SCM pour ignorer main.o et main.

Le point est le suivant: les extensions ne sont pas utilisées comme elles le sont dans Windows. Le noyau n'exécutera pas un fichier .txt car vous supprimez la partie .txt du nom. Il est également très heureux d'exécuter un fichier .txt si l'autorisation d'exécution est définie. Cela étant dit, ils ont un sens et sont toujours utilisés sur un "niveau informatique" pour beaucoup de choses.


5
2017-07-27 09:15



Windows n'est pas non plus lié à la x.3 schéma de nommage plus, vous avez de plus longues extensions là-bas comme .doxc, .torrent, .partC'est juste que beaucoup de formats de fichiers et d'extensions étaient déjà définis à l'époque où la dénomination 8.3 était encore une chose et que les formats ultérieurs adaptaient simplement la convention d'utilisation de 3 lettres au maximum. - Byte Commander
Je ne vois pas comment ".conf", ".c", etc. sont "un sens différent" du "sens 8.3". Le concept d'extension de fichier peut être simplement exprimé comme "une convention d'identification du type d'un fichier basé sur une partie de son nom". Pas même DOS / Win3.1 Champs obligatoires l'extension correcte (vous pouvez appeler un document Word "STUPIDN.AME" et l'ouvrir avec Ctrl-O dans WinWord). C'est juste que certains systèmes (par exemple, double-cliquez sur Windows, gzip, votre Makefile, etc) peut être écrit pour utiliser cette convention pour faire des suppositions sur la bonne action à entreprendre sur chaque fichier. - IMSoP
@ByteCommander C'est vrai, mais l'extension détermine toujours l'application utilisée. Je ne sais pas comment modifier la réponse pour refléter cela. - coteyr
@coteyr Encore une fois, tout dépend de ce que nous entendons par "l'OS". le Gestionnaire de fichiers va certainement chercher une clé de registre pour "AME", et me dira que "foo.txt" est un fichier texte. Mais en cours d'exécution dir à une invite de commande ne me dira rien de tel; ça ne va tout simplement pas s'en soucier. L'exécution de fichiers est certainement une exception sur les deux systèmes d'exploitation. si la question était limitée à ceux-ci, la réponse serait que DOS / Windows seulement soucieux du nom, et Unix / Linux seulement soucier de l'autorisation d'exécution et les premiers octets du fichier. En dehors de cela, il y a toujours une application qui choisit une convention à suivre. - IMSoP
@coteyr Vous avez oublié * .scr (écran de veille binaire) dans Windows 3.1 et les versions ultérieures. Cela dit, l’extension de fichier, même dans les systèmes DOS / Windows, même pour les exécutables, est encore juste une commodité. Les spécificités dépendent beaucoup de l'endroit où vous tracez la ligne du "système d'exploitation", mais vous pouvez toujours charger un binaire en mémoire et y accéder vous-même, en faisant le travail que l'on demande normalement au système d'exploitation. Sous MS-DOS, si vous consultez command.com, je suis sûr qu'il existe une liste comme EXE COM que vous pouvez modifier de manière à rechercher d'autres extensions si aucune n'est spécifiée (ne pas dire que ce serait une bonne idée, attention à toi). - Michael Kjörling