Vraag Hebben bestandsextensies enig doel (voor het besturingssysteem)?


Linux bepaalt het type bestand via een code in de bestandsheader. Het is niet afhankelijk van bestandsextensies om te weten welke software moet worden gebruikt om het bestand te openen.

Dat is wat ik me herinner van mijn opleiding. Corrigeer me als ik het mis heb!

Ik werkte onlangs een beetje met Ubuntu-systemen: ik zie veel bestanden op de systemen met extensies zoals .sh, .txt, .o, .c

Nu vraag ik me af: zijn deze uitbreidingen alleen bedoeld voor mensen? Zodat iemand een idee zou moeten krijgen van wat voor soort bestand het is?

Of hebben ze ook een bepaald doel voor het besturingssysteem?


66
2017-07-27 06:46


oorsprong


Als je hier geen goed antwoord krijgt, onthoud dat dat ook zo is unix.stackexchange.com - mchid
@mchid Heel erg bedankt. Dat is erg aardig van je. - mizech
Gerelateerd, bijna duplicaat: askubuntu.com/questions/390015/... - Zzzach...
In Windows doen ze dat in Linux / Unix meestal niet. De belangrijkste uitzondering zijn de compressieprogramma's - gzip, bzip2, xz - enzovoort. Deze programma's gebruiken achtervoegsels om de gecomprimeerde versie van een bestand te scheiden van de ongecomprimeerde versie die ze vervangen. Compressieprogramma's klagen vaak over onjuist achtervoegsel, hoewel het bestand in feite een gecomprimeerd bestand is van het type dat het moet verwerken. - Baard Kopperud
Ik denk dat een deel van het probleem met deze vraag is dat "het besturingssysteem" geen goed gedefinieerd concept is. Wat maakt deel uit van het besturingssysteem en wat is een applicatie erbovenop? Niet veel delen van het besturingssysteem (welk besturingssysteem we ook bedoelen) geven om welk type een bestand het gaat - ze doen gewoon wat ze worden verteld. Dus onderscheidingen over hoe ze weten dat ze niet relevant zijn; zij doen geen van beide. Applcations, aan de andere kant, kan goed een of beide dingen doen. - IMSoP


antwoorden:


Linux bepaalt het type bestand via een code in de bestandskop. Het hangt niet af van bestandsextensies die u moet weten om met software het bestand te openen.

Dat is wat ik me herinner van mijn opleiding. Corrigeer me als ik het mis heb!

  • correct onthouden.

Zijn deze uitbreidingen alleen bedoeld voor mensen?

  • Ja, met een maar.

Wanneer u met andere besturingssystemen communiceert die ervan afhankelijk zijn dat extensies zijn zoals ze zijn, is het een slimmer idee om deze te gebruiken.

In Windows is openingssoftware gekoppeld aan de uitbreidingen.

Het openen van een tekstbestand met de naam "bestand" is moeilijker in Windows dan het openen van hetzelfde bestand met de naam "file.txt" (u moet het bestand openen dialoogvenster van *.txt naar *.* elke keer). Hetzelfde geldt voor TAB en puntkomma's gescheiden tekstbestanden. Hetzelfde geldt voor het importeren en exporteren van e-mails (.mbox-extensie).

In het bijzonder wanneer u software codeert. Het openen van een bestand met de naam "software1" dat een HTML-bestand is en "software2" dat een JavaScript-bestand is, wordt moeilijker in vergelijking met "software.html" en "software.js".


Als er in Linux een systeem is waar bestandsextensies belangrijk zijn, zou ik dat een bug noemen. Wanneer software afhankelijk is van bestandsextensies, is dat te exploiteren. We gebruiken een tolkrichtlijn om te identificeren wat een bestand is ("de eerste twee bytes in een bestand kunnen de karakters zijn" #! ", die een magisch getal vormen (hexadecimaal 23 en 21, de ASCII-waarden van" # "en"! ") die vaak worden gebruikt as shebang, ").

Het bekendste probleem met bestandsextensies was LOVE-LETTER-FOR-YOU.TXT.vbs op Windows. Dit is een visueel basisscript dat in bestandsverkenner wordt weergegeven als een tekstbestand.

In Ubuntu krijg je een melding van wat het gaat doen als je een bestand van Nautilus start. Het uitvoeren van een script van Nautilus waar het software wil starten waar het gEdit zou moeten openen, is overduidelijk een probleem en we krijgen een waarschuwing.

In de opdrachtregel wanneer u iets uitvoert, kunt u visueel zien wat de extensie is. Als het eindigt op .vbs zou ik verdacht worden (niet dat .vbs uitvoerbaar is onder Linux. Althans niet zonder wat meer moeite;)).


37
2017-07-27 07:01



Ik begrijp helemaal niet wat je wilde zeggen in je laatste zin. Ten eerste is het een probleem om de extensie te verbergen in plaats van deze te hebben, ten tweede zou de exploit hetzelfde werken in Linux - je noemt een binair bestand readme.txt en maak het uitvoerbaar. Als de gebruiker het heeft uitgevoerd, wordt de editor niet geopend, maar wordt de code uitgevoerd. In dit opzicht is het maken van uitbreidingen van belang (maar niet verbergen) is veiliger en gemakkelijker uit te leggen voor niet-slimme gebruikers. Er zijn nog andere verschillen (met name het niet uitvoeren van bestanden uit de huidige map), maar ze hebben niets te maken met extensies. - techraf
@techraf Eigenlijk het bestandsbeheer zal waarschijnlijk proberen het readme.txt bestand met een teksteditor. Ik heb het zojuist geprobeerd met Dolphin in KDE, een shellscript creërende uitvoerbare toestemming toe te voegen, het opslaan als .txt en als je erop klikt, wordt het in Kate geopend. Als ik het hernoem .sh vervolgens wordt er op geklikt. - Bakuriu
linux: vermits make is gebouwd rond regels die afhankelijk zijn van de extensie, zou dit niet maken (geen woordspeling bedoeld) de extensies bedoeld voor meer dan alleen mensen? - bolov
Dit is een monumentaal verkeerd antwoord. Sommige delen van Linux gebruiken magische nummers om bestandstypen te bepalen. Bestanden uitvoeren op de opdrachtregel. Maar andere grote delen van het systeem gebruiken bestandsextensies om te weten waarnaar moet worden gekeken, of dat nu de dynamische linker (die .so-bestanden wil), modprobe, build-systemen, plug-ins, bibliotheken voor python, robijn, enz. Zijn. Veel bestanden niet t heb magische getallen, file is gebaseerd op heuristiek, niet bepaald. - Alan Shutko
"Linux bepaalt het type bestand via een code in de bestandskop" "correct" WTF? Welke "code in de bestandskop"? Er is geen dergelijke code en er is geen dergelijke generieke "bestandskop" in Linux. - leonbloy


Er is geen 100% zwart of wit antwoord hier.

doorgaans Linux vertrouwt niet op bestandsnamen (en bestandsextensies, d.w.z. het deel van de bestandsnaam na de normaal vorige periode) en bepaalt in plaats daarvan het bestandstype door de eerste paar bytes van de inhoud te onderzoeken en die te vergelijken met een lijst met bekende magische nummers.

Bijvoorbeeld alle Bitmap-afbeeldingsbestanden (meestal met naamuitbreiding .bmp) moet beginnen met de letters BM in hun eerste twee bytes. Scripts in de meeste scripttalen zoals Bash, Python, Perl, AWK, etc. (eigenlijk alles dat lijnen behandelt die beginnen met # als commentaar) kan een shebang-achtig bevatten #!/bin/bash als eerste regel. Deze speciale opmerking vertelt het systeem met welke toepassing het bestand moet worden geopend.

Dus normaal vertrouwt het besturingssysteem op de bestandsinhoud en niet op de naam ervan om het bestandstype te bepalen, maar stellen dat bestandsextensies nooit nodig zijn op Linux is slechts de helft van de waarheid.


Toepassingen kunnen natuurlijk hun controles van bestanden implementeren, zoals ze willen, inclusief het verifiëren van de bestandsnaam en extensie. Een voorbeeld is het Eye of Gnome (eog, standaard fotoviewer) die het beeldformaat bepaalt door de bestandsextensie en een fout genereert als deze niet overeenkomt met de inhoud. Of dit een bug of een functie is, kan worden besproken ...

Zelfs sommige delen van het besturingssysteem zijn echter afhankelijk van bestandsnaamextensies, bijvoorbeeld bij het ontleden van uw softwarebronbestanden /etc/apt/sources.list.d/ - alleen bestanden met de *.list uitbreiding wordt geparseerd en alle andere worden genegeerd. Het wordt misschien niet hoofdzakelijk gebruikt om het bestandstype hier te bepalen, maar om het parseren van sommige bestanden in / uit te schakelen, maar het is nog steeds een bestandsextensie die invloed heeft op hoe het systeem een ​​bestand behandelt.

En natuurlijk profiteert de menselijke gebruiker het meest van bestandsextensies omdat dat het type van een bestand duidelijk maakt en ook meerdere bestanden met dezelfde basisnaam en verschillende extensies zoals site.html, site.php, site.js, site.css enz. Het nadeel is natuurlijk dat de bestandsextensie en het daadwerkelijke bestandstype / inhoud niet noodzakelijkerwijs moeten overeenkomen.

Daarnaast is het nodig voor platformonafhankelijke interoperabiliteit, zoals b.v. Windows weet niet wat te doen met een readme bestand, maar alleen een readme.txt.


64
2017-07-27 07:22



Je spreekt jezelf hier enigszins tegen: als de standaardbeeldviewer een bestandsnaam vereist die eindigt op .bmp, welk deel van het besturingssysteem zegt u dan te vertrouwen op de inhoud van het bestand die begint met "BM"? AFAIK, de enige 'magische nummers waar de kernel om geeft, zijn uitvoerbare typen, inclusief het speciale geval van #!. Al het andere is aan de beslissing van een bepaalde applicatie. - IMSoP
@IMSoP Ik weet niet de exacte implementatie van eog en ik weet niet waarom ze überhaupt om de bestandsnaam geven. Dit is naar mijn mening een fout. En natuurlijk, als het bestand de naam "bmp" heeft, maar het inhoudsformaat niet overeenkomt, is er natuurlijk ook een fout. Natuurlijk beslist elke applicatie hoe bestanden moeten worden gecontroleerd, maar in het algemeen zouden Linux-applicaties niet op de naam moeten vertrouwen. Trouwens, je kunt het gebruiken file beveel aan bestandstypes te onderzoeken op hun inhoud. - Byte Commander
De zin die ik uitdaag is deze: "Linux ... bepaalt het bestandstype door de eerste paar bytes te bekijken". Welke definitie van "Linux" gebruikt u in die zin? Het bestaan ​​van de file utility bewijst niet echt iets; het is een handige tool die op elk OS kan bestaan. Welk fundamenteel onderdeel van het OS maakt hardlopen file meer "correct" dan globpen de bestandsnaam? - IMSoP
Merk op dat bestanden zonder extensie zijn kan geassocieerd zijn met een programma. - isanae


Zoals door anderen wordt vermeld, wordt in Linux een methode voor tolkrichtlijnen gebruikt (het opslaan van sommige metadata in een bestand als een header of een magisch nummer, zodat de juiste tolk kan worden verteld om het te lezen) in plaats van de bestandsnaamextensie-associatiemethode die door Windows wordt gebruikt.

Dit betekent dat je een bestand kunt maken met bijna elke naam die je wilt ... met een paar uitzonderingen

Echter

Ik wil graag een waarschuwing toevoegen.

Als u bestanden op uw systeem hebt staan ​​van een systeem dat associatie van bestandsnamen gebruikt, hebben de bestanden mogelijk niet die magische nummers of koppen. Bestandsnaamextensies worden gebruikt om deze bestanden te identificeren door applicaties die deze kunnen lezen en u kunt een aantal onverwachte effecten ervaren als u dergelijke bestanden een andere naam geeft. Bijvoorbeeld:

Als u de naam van een bestand wijzigt My Novel.doc naar My-Novel, Libreoffice kan het nog steeds openen, maar het wordt geopend als 'Naamloos' en u moet het opnieuw een naam geven om het op te slaan (Libreoffice voegt standaard een extensie toe, zodat u dan twee bestanden zou hebben My-Novel en My-Novel.odt, wat vervelend zou kunnen zijn)

Meer serieus, als u een bestand Mijn spreadsheet.xlsx naar Mijn-spreadsheet hernoemt, probeer het dan te openen met xdg-open My-Spreadsheetje krijgt dit (omdat het eigenlijk een gecomprimeerd bestand is):

En als je een bestand hernoemt My Spreadsheet.xls naar My-Spreadsheet, wanneer je xdg-open My-Spreadsheet je krijgt een foutmelding

error opening location: Geen enkele applicatie is geregistreerd als behandeling van dit bestand

(Hoewel in beide gevallen het OK werkt als je dat doet soffice My-Spreadsheet)

Als u dan het extensionless-bestand hernoemt in My-Spreadsheet.ods met mv en probeer het te openen. Je krijgt dit:

(reparatie mislukt)

En u moet de oorspronkelijke extensie opnieuw plaatsen om het bestand correct te openen (u kunt het formaat vervolgens converteren als u dat wilt)

TL; DR:

Als je niet-native bestanden met naamextensies hebt, verwijder dan niet de extensies ervan uitgaande dat alles in orde zal zijn!


23
2017-07-27 08:06



Een nieuw MS Office-document (docx, xlsx, pptx enz.) Zonder bestandsextensie wordt geopend in Archiefbeheer, omdat deze bestandstypen eigenlijk gewone ZIP-gecomprimeerde bestanden zijn die alle XML-documenten en mediabestanden bevatten die nodig zijn om de documentinhoud te definiëren. Het bestandsformaat van een gecomprimeerde ZIP-directory is tegenwoordig vrij gewoon. - Byte Commander
Al veel goede antwoorden, maar nog een specifiekere voor libreoffice die ik heb opgemerkt. U maakt een bestand met door komma's gescheiden waarden (CSV) en slaat het op als "test.csv", er wordt een venster geopend met de vraag welk type scheidingsteken u gebruikt (d.w.z. libreoffice Calc). Als u dit bestand bijvoorbeeld de naam "test.cs" geeft, wordt het geopend door de schrijver van libreoffice. Dus, afgezien van het bovenstaande ZIP-voorbeeld lijkt het wel of LibreOffice de bestandsextensie gebruikt. - Ray
Het linux-bestandssysteem doet niets met betrekking tot bestandstypen. Dat komt allemaal door de programma's die er bovenop draaien. - Peter Green
@ Peter Green Ja, maar het feit dat de programma's er betekenis aan toekennen, betekent dat het niet 'alleen voor mensen' is, zoals het klassieke MacOS het had [er waren vier-byte "bestandstype" en "schepperapp" -velden die weren ' t deel van de bestandsnaam, zodat het besturingssysteem en de applicaties alle informatie hadden die ze nodig hadden zonder naar bestandsextensies te kijken] - Random832
@PeterGreen Het Windows-bestandssysteem doet ook niets met betrekking tot bestandstypen. De grafische schil (Windows Explorer) gebruikt een bestandsextensie om een ​​actie te kiezen voor dubbelklikken, maar technisch gezien is dat slechts een programma dat bovenop het besturingssysteem draait, net als Nautilus. Het zou perfect mogelijk zijn om een ​​Linux-bestandsbeheerder met dat gedrag te schrijven, of een Windows-versie die de inhoud van het bestand onderzocht. - IMSoP


Ik zou dit graag op een andere manier benaderen dan andere antwoorden, en de opvatting uitdagen dat "Linux" of "Windows" hier iets mee te maken hebben (met mij mee).

Het concept van een bestandsextensie kan eenvoudig worden uitgedrukt als "een conventie voor het identificeren van het type bestand op basis van een deel van de naam". De andere gangbare conventies voor het identificeren van het type bestand vergelijken de inhoud ervan met een database van bekende handtekeningen (de "magic number" -benadering), en slaan het op als een extra attribuut op het bestandssysteem (de aanpak die wordt gebruikt in de originele MacOS) .

Omdat elk bestand op een Windows- of Linux-systeem zowel een naam als een inhoud heeft, kunnen processen die het bestandstype willen kennen, de "uitbreiding" of de "magische nummer" -benadering gebruiken zoals zij dat nodig achten. De benadering met metadata is niet algemeen beschikbaar, omdat er op de meeste bestandssystemen geen standaardplaats is voor dit kenmerk.

In Windows is er een sterke traditie van het gebruik van de bestandsextensie als het primaire middel om een ​​bestand te identificeren; het meest zichtbaar, de grafische bestandsbrowser (Bestandsbeheer op Windows 3.1 en Explorer op modern Windows) gebruikt het wanneer u dubbelklikt op een bestand om te bepalen welke toepassing moet worden gestart. Op Linux (en meer in het algemeen op Unix gebaseerde systemen) is er meer traditie om de inhoud te inspecteren; met name kijkt de kernel naar het begin van een rechtstreeks uitgevoerd bestand om te bepalen hoe het moet worden uitgevoerd; scriptbestanden kunnen een tolk aangeven om te gebruiken door te beginnen met #! gevolgd door het pad naar de tolk.

Deze tradities beïnvloeden het UI-ontwerp van programma's die voor elk systeem zijn geschreven, maar er zijn veel uitzonderingen, omdat elke benadering voor- en nadelen heeft in verschillende situaties. Redenen om bestandsextensies te gebruiken in plaats van de inhoud te onderzoeken, zijn onder andere:

  • het onderzoeken van bestandsinhouden is vrij duur in vergelijking met het onderzoeken van bestandsnamen; dus "vind alle bestanden met de naam * .conf" een stuk sneller dan "vind alle bestanden waarvan de eerste regel overeenkomt met deze handtekening"
  • bestandsinhoud kan dubbelzinnig zijn; veel bestandsformaten zijn eigenlijk alleen tekstbestanden die op een speciale manier worden behandeld, vele anderen zijn speciaal gestructureerde zip-bestanden en het definiëren van nauwkeurige handtekeningen voor deze kan lastig zijn
  • een bestand kan echt als meer dan één type geldig zijn; een HTML-bestand kan ook een geldige XML zijn, een zip-bestand en een aaneengeschakelde GIF blijven voor beide formaten geldig
  • magische nummeraanpassing kan leiden tot valse positieven; een bestandsindeling zonder kopregel kan beginnen met de bytes "GIF89a" en kan ten onrechte worden aangemerkt als een GIF-afbeelding
  • het hernoemen van een bestand kan een handige manier zijn om het te markeren als "uitgeschakeld"; bijv. "foo.conf" wijzigen in "foo.conf ~" om aan te geven dat een back-up gemakkelijker is dan het bewerken van het bestand om alle richtlijnen te becommentariëren, en handiger dan het uit een automatisch geladen map te halen; op dezelfde manier zal het hernoemen van een .php-bestand naar .txt Apache zijn bron als platte tekst laten dienen, in plaats van het door te geven aan de PHP-engine

Voorbeelden van Linux-programma's die standaard bestandsnamen gebruiken (maar mogelijk andere modi hebben):

  • gzip en gunzip hebben een speciale afhandeling van elk bestand dat eindigt op ".gz"
  • gcc verwerkt ".c" bestanden als C, en ".cc" of ".C" als C ++

19
2017-07-27 17:13



Windows heeft ook een sterke traditie van het verbergen van de extensie als deze "bekend" is en zelfs DOS een opdracht toestaat om .COM, .BAT en .EXE weg te laten, automatisch op zoek naar die extensie om te bepalen welk programma feitelijk moet worden uitgevoerd. Er is geen dergelijke traditie in * nix. - Monty Harder
Dit zou het geaccepteerde antwoord moeten zijn. - Ave
Dit is een veel beter antwoord maar heeft één feitelijke fout ... een script kan niet uitvoerbaar worden gemaakt door het te plaatsen #! in het begin. Elk bestand met zijn uitvoerbare bit (s) -set kan op verschillende manieren worden uitgevoerd. #!/bin/bash en soortgelijke handtekeningen geven alleen aan welke tolk moet worden gebruikt. Als er geen dergelijke handtekening wordt opgegeven, wordt de standaard shell-interpreter verondersteld. Een bestand dat niets anders bevat dan de twee woorden 'Hallo wereld', maar met zijn bitset voor uitvoering, zal het proberen een 'Hallo'-opdracht te vinden wanneer het wordt uitgevoerd. - DocSalvager
@DocSalvager Goede vangst, dat was zo onhandig geformuleerd als alles. Ik heb het een beetje anders geformuleerd om duidelijk te maken dat de shebang dat niet doet maken het script uitvoerbaar, het verandert gewoon hoe het is uitgevoerd. - IMSoP


Eigenlijk, sommige technologieën do vertrouw op bestandsextensies, dus als u die technologieën in Ubuntu gebruikt, moet u ook op extensies vertrouwen. Een paar voorbeelden:

  • gcc maakt gebruik van extensies om een ​​onderscheid te maken tussen C en C ++ -bestanden. Zonder de extensie is het vrijwel onmogelijk om ze te onderscheiden (stel je een C ++ -bestand voor zonder klassen).
  • veel bestanden (docx, jar, apk) zijn gewoon bijzonder gestructureerde ZIP-archieven. Hoewel u meestal het type uit de inhoud kunt afleiden, is dit misschien niet altijd mogelijk (bijvoorbeeld Java Manifest) facultatief in jar bestanden).

Geen gebruik van bestandsextensies is in dergelijke gevallen alleen mogelijk met hacky-oplossingen en is waarschijnlijk zeer foutgevoelig.


14
2017-07-27 15:52



Goed dat je programmeren noemt, maar je hebt de meeste details verkeerd. gcc is de front-end voor C-bestanden, voor C ++ -bestanden hebt u de g++ front-end of een opdrachtregel om de taal te specificeren. Belangrijker is het make programma dat beslist om te gebruiken gcc of g++ om een ​​bepaald bestand te bouwen - en make is volledig afhankelijk van bestandsnaampatronen (meestal extensies) voor het matchen van regels. - Ben Voigt
@BenVoigt Bij het compileren van een bestand met een .cc uitbreiding met gcc, het zal echt worden gecompileerd als C ++, en dit is gedocumenteerd in man gcc: "Voor elk ingevoerd bestand bepaalt het achtervoegsel van de bestandsnaam wat voor soort compilatie wordt gedaan:" gevolgd door een lijst met extensies en hoe deze worden behandeld. - hvd
@hvd Dan is het misschien de standaard verzameling bibliotheken die vreselijk mis gaat als je niet de juiste frontend gebruikt. Make is in elk geval het beste voorbeeld, omdat alles wat het doet is gebaseerd op een bestandsextensie. - Ben Voigt
@BenVoigt make is ook een goed voorbeeld, maar gcc vertrouwt net zo zwaar op bestandsnamen. Hier is een voorbeeld dat duidelijker is dan .c vs .cc: Voor C, gcc gebruikt achtervoegsels om aan te geven of de eerste stap is om voor te verwerken (.c), compileren (.i), monteren (.s) of link (.o). Hier gebruik ik -E, -S en -c vertellen gcc waarheen hou op, maar het gebruikt bestandsnamen om te weten waarheen begin.  gcc something.cc zal niet linken naar de juiste bibliotheken voor C ++ maar het zullen behandel het bestand als C ++, waardoor veel gebruikers in verwarring raken door de foutmeldingen die ze krijgen bij het maken van die fout. - Eliah Kagan


Je eerste aanname is correct: de uitbreidingen op Linux doen er niet toe en zijn alleen nuttig voor mensen (en andere niet-Unix-achtige OS die om extensies geven). Het type bestand wordt bepaald door de eerste 32 bits aan gegevens in het bestand, dat bekend staat als magisch nummer Dit is de reden waarom shell-scripts nodig hebben #! regel - om het besturingssysteem te vertellen welke tolk moet worden gebeld. Zonder dit is het shellscript alleen maar een tekstbestand.

Wat bestandsbeheerders betreft, willen ze extensies van sommige bestanden kennen, zoals .desktop bestanden, die in principe hetzelfde zijn als Window's versie van snelkoppelingen, maar met meer mogelijkheden. Maar wat OS betreft, moet het weten wat er in het bestand staat, niet wat in zijn naam staat


7
2017-07-27 07:02



Dit is niet helemaal waar. Er zijn programma's die een specifieke extensie verwachten. Het meest gebruikte voorbeeld is waarschijnlijk gunzip die een bestand niet zal decomprimeren als het niet wordt opgeroepen foo.gz. - terdon♦
Dat is een implementatie van specifieke software. Over het algemeen verwachten utilities op unix-achtige systemen geen extensie. - Sergiy Kolodyazhnyy
Voor het grootste gedeelteze doen niet, nee. Je eerste zin beweert echter dat ze nooit worden gebruikt en alleen van belang zijn voor de mens. Dat is niet helemaal waar. gunzip is een voorbeeld, eog is een ander. Ook zullen veel tools namen niet automatisch aanvullen zonder de juiste extensie. Ik wil alleen maar zeggen dat het een beetje ingewikkelder is dan 'extensies zijn altijd irrelevant'. - terdon♦
1 klein probleem: OP vroeg naar het besturingssysteem. 'gunzip' en 'eog' zijn niet het besturingssysteem, maar besloten om hun eigen beperkingen (in het geval van gunzip) of methode (eog) te maken. "mimesoorten". - Rinzwind
@Serg Natuurlijk, je kunt OS eng definiëren en een triviaal antwoord op de vraag krijgen. Dit is echter geen bijzonder nuttig antwoord, omdat de overgrote meerderheid van wat een gebruiker met een computer doet, betrekking heeft op software die u hebt uitgesloten. Merk op dat de vraag in contrast stond met "alleen voor mensen" tegen "het besturingssysteem"; Ik denk niet dat ze "de kernel" betekenden. - IMSoP


Dit is te groot voor een reactieantwoord.

Houd er rekening mee dat zelfs "extensie" veel betekent als verschillende betekenissen.

Waar je over praat lijkt de 3 letters na de. DOS maakte het 8.3-formaat echt populair en Windows gebruikt het .3-deel tot op de dag van vandaag.

Linux heeft veel bestanden zoals .conf of .list of .d of .c die betekenis hebben, maar zijn niet echt extensies in de 8.3-zin. Apache kijkt bijvoorbeeld naar /etc/apache2/sites-enabled/website.conf voor zijn configuratierichtlijn. Hoewel het systeem MIME-typen en inhoudsheaders gebruikt en niet bepaalt dat het een tekstbestand is, zal Apache (standaard) dit nog steeds niet laden zonder dat het eindigt op .conf.

.c is een andere geweldige. Yep het is een tekstbestand, maar gcc is afhankelijk van main.c en wordt main.o en uiteindelijk main (na linking). Op geen enkel moment gebruikt het systeem de .c, .o of geen extensie om enige betekenis te hebben voor wat betreft de inhoud, maar de dingen na de. heeft enige betekenis. U zou waarschijnlijk uw SCM instellen om main.o en main te negeren.

Het punt is dat dit is: extensies worden niet gebruikt zoals ze in windows voorkomen. De kernel voert geen .txt-bestand uit omdat u het .txt-gedeelte van de naam verwijdert. Het is ook erg blij om een ​​.txt-bestand uit te voeren als de uitvoeringsmachtiging is ingesteld. Dat gezegd hebbende, ze hebben wel degelijk betekenis en worden nog steeds op een "computerniveau" gebruikt voor veel dingen.


5
2017-07-27 09:15



Windows is ook niet gebonden aan de x.3 naamgevingsschema meer, je hebt daar ook verlengde extensies zoals .doxc, .torrent, .part, etc. Het is gewoon zo dat veel bestandsindelingen en extensies al werden gedefinieerd in de tijd dat 8.3-naamgeving nog steeds een ding was en dat latere formaten meestal eenvoudigweg de conventie van het gebruik van maximaal 3 letters hebben aangepast. - Byte Commander
Ik zie niet hoe ".conf", ".c", enz., "Een andere betekenis" hebben dan "de 8.3-zin". Het concept van een bestandsextensie kan eenvoudig worden uitgedrukt als "een conventie voor het identificeren van het type bestand op basis van een deel van de naam". Zelfs DOS / Win3.1 niet verplicht de juiste extensie (je zou een Word-document "STUPIDN.AME" kunnen noemen en het openen met Ctrl-O in WinWord). Het is gewoon dat sommige systemen (bijvoorbeeld dubbelklikken op Windows, gzip, uw Makefile, enz.) kunnen worden geschreven om deze conventie te gebruiken om veronderstellingen te maken over de juiste actie die elk bestand moet nemen. - IMSoP
@ByteCommander Dat klopt, maar de extensie bepaalt nog steeds de gebruikte app. Ik weet niet zeker hoe ik het antwoord moet bewerken om dat te weerspiegelen. - coteyr
@coteyr Nogmaals, het hangt er helemaal vanaf wat we bedoelen met "het OS". De Bestandsbeheer zal zeker een registersleutel opzoeken voor "AME", en zal me vertellen dat "foo.txt" een tekstbestand is. Maar rennen dir bij een opdrachtprompt zal me dat niet vertellen; het kan gewoon niet schelen. Het uitvoeren van bestanden is zeker een uitzondering, in beide besturingssystemen; als de vraag beperkt was tot die, zou het antwoord zijn dat DOS / Windows enkel en alleen geef om de naam en Unix / Linux enkel en alleen zorg voor de execute permissie en de eerste bytes van het bestand. Buiten dat, is er altijd een applicatie die een conventie kiest om te volgen. - IMSoP
@coteyr U bent * .scr (binaire schermbeveiliging) in Windows 3.1 en hoger vergeten. Dat gezegd hebbende, de bestandsextensie zelfs in DOS / Windows-systemen, zelfs voor uitvoerbare bestanden is nog steeds gewoon een gemak. De details hangen sterk af van waar je de regel "operating system" tekent, maar je kunt altijd een binary in het geheugen laden en er zelf in springen, terwijl je het werk doet dat men normaal van het besturingssysteem vraagt. Als je in MS-DOS door command.com kijkt, ben ik er vrij zeker van dat er een lijst zoals EXE COM is die je zo kunt bewerken dat hij naar andere extensies zoekt als er geen is gespecificeerd (niet zeggen dat het een goed idee zou zijn, Let wel). - Michael Kjörling