As extensões de arquivo têm algum objetivo (para o sistema operacional)?

73

O Linux determina o tipo de um arquivo por meio de um código no cabeçalho do arquivo. Não depende de extensões de arquivo para saber qual software deve ser usado para abrir o arquivo.

É disso que lembro da minha educação. Por favor, me corrija caso eu esteja errado!

Trabalhando um pouco com sistemas Ubuntu recentemente: Eu vejo um monte de arquivos nos sistemas que têm extensões como .sh, .txt, .o,.c

Agora, estou me perguntando: essas extensões são destinadas apenas a humanos? Para que se tenha uma idéia de que tipo de arquivo é?

Ou eles também têm algum objetivo para o sistema operacional?

files file-format mime-type

— mizech
fonte

5

Se você não obtiver uma boa resposta aqui, lembre-se, há também unix.stackexchange.com

— mchid

Relacionado, quase duplicado: askubuntu.com/questions/390015/…

— Zzzach ...

relacionado: unix.stackexchange.com/questions/207276/…

— caos

5

No Windows, no Linux / Unix, na maioria das vezes não. A principal exceção são os de compressão-programas - gzip, bzip2, xz- e assim por diante. Esses programas usam sufixos para separar a versão compactada de um arquivo da versão não compactada que eles substituem. Os programas de compactação costumam reclamar de sufixos incorretos, mesmo que o arquivo seja realmente um arquivo compactado do tipo que ele deve manipular.

— Baard Kopperud

6

Eu acho que parte do problema dessa pergunta é que "o sistema operacional" não é um conceito bem definido. O que faz parte do sistema operacional e o que é um aplicativo em cima dele? Poucas partes do sistema operacional (seja qual for o sistema operacional de que estamos falando) se importam com o tipo de arquivo - elas apenas fazem o que lhes é solicitado. Portanto, distinções sobre como eles sabem são irrelevantes; eles também não. As aplicações, por outro lado, podem muito bem fazer uma ou ambas as coisas.

— IMSoP 27/07

39

O Linux determina o tipo de um arquivo através de um código no cabeçalho do arquivo. Não depende de extensões de arquivo para saber com o software é usado para abrir o arquivo.

É disso que lembro da minha educação. Por favor, me corrija caso eu esteja errado!

lembrado corretamente.

Essas extensões são destinadas apenas a humanos?

Sim, com um mas.

Quando você interage com outros sistemas operacionais que dependem de extensões, o ideal é usá-las.

No Windows, o software de abertura está anexado às extensões.

Abrir um arquivo de texto chamado "arquivo" é mais difícil no Windows do que abrir o mesmo arquivo "arquivo.txt" (será necessário alternar a caixa de diálogo de abertura do arquivo *.txtpara *.*sempre). O mesmo vale para arquivos de texto separados por TAB e ponto-e-vírgula. O mesmo vale para importar e exportar emails (extensão .mbox).

Em particular quando você codifica software. Abrir um arquivo chamado "software1", que é um arquivo HTML, e "software2", que é um arquivo JavaScript, se torna mais difícil em comparação com "software.html" e "software.js".

Se existe um sistema no Linux em que as extensões de arquivo são importantes, eu chamaria isso de bug. Quando o software depende das extensões de arquivo, isso é explorável. Utilizamos uma diretiva de intérprete para identificar o que é um arquivo ("os dois primeiros bytes de um arquivo podem ser os caracteres" #! ", Que constituem um número mágico (hexadecimal 23 e 21, os valores ASCII de" # "e"! ") geralmente chamado de shebang").

O problema mais famoso com extensões de arquivo foi LOVE-LETTER-FOR-YOU.TXT.vbs no Windows. Este é um script visual básico sendo mostrado no explorador de arquivos como um arquivo de texto.

No Ubuntu, quando você inicia um arquivo do Nautilus, recebe um aviso sobre o que ele fará. A execução de um script do Nautilus, onde ele deseja iniciar algum software onde ele deve abrir o gEdit, é obviamente um problema e recebemos um aviso sobre isso.

Na linha de comando, quando você executa algo, pode ver visualmente qual é a extensão. Se terminar em .vbs, eu começaria a suspeitar (não que .vbs seja executável no Linux. Pelo menos não sem mais esforço;)).

— Rinzwind
fonte

31

Não entendi completamente o que você queria dizer na sua última frase. Primeiro, é um problema de ocultar a extensão em vez de tê-la; depois, a exploração funcionaria da mesma maneira no Linux - você nomeia um arquivo binário readme.txte o torna executável. Se o usuário o executou, ele não abre o editor, mas executa o código. Nesse sentido, tornar as extensões importantes (mas não escondê-las) é mais seguro e fácil de explicar para usuários não experientes. Existem outras diferenças (principalmente a execução de arquivos do diretório atual), mas elas não têm nada a ver com extensões.

— techraf

4

@techraf Na verdade, o gerenciador de arquivos provavelmente tentará abrir o readme.txtarquivo com um editor de texto. Eu apenas tentei com o dolphin no KDE, criando um shell script adicionando permissão executável, salvando-o como .txte clicando nele para abrir o Kate. Se eu renomeá-lo para .shclicar nele, ele será executado.

— Bakuriu 27/07/16

9

linux: como make é construído em torno de regras que dependem da extensão do arquivo, isso não tornaria (sem trocadilhos) as extensões destinadas a mais do que apenas seres humanos?

— bolov 27/07/16

15

Esta é uma resposta monumentalmente errada. Algumas partes do Linux usam números mágicos para determinar os tipos de arquivo. Executando arquivos na linha de comando. Mas outras grandes partes do sistema usam extensões de arquivo para saber o que procurar, sejam elas o vinculador dinâmico (que deseja arquivos .so), modprobe, sistemas de compilação, plugins, bibliotecas para python, ruby etc. Muitos arquivos não são usados. não possui números mágicos, fileé baseado em heurística, não é definitivo.

— 27416 Alan Shutko

3

"O Linux determina o tipo de um arquivo através de um código no cabeçalho do arquivo" "correto" WTF? Qual "código no cabeçalho do arquivo"? Não existe esse código e não existe um "cabeçalho de arquivo" genérico no Linux.

— Leonbloy 30/07/16

68

Não há resposta 100% em preto ou branco aqui.

Normalmente, o Linux não depende de nomes de arquivo (e extensões de arquivo, ou seja, a parte do nome do arquivo após o último período normalmente) e, em vez disso, determina o tipo de arquivo examinando os primeiros bytes de seu conteúdo e comparando-o a uma lista de números mágicos conhecidos. .

Por exemplo, todos os arquivos de imagem de bitmap (geralmente com extensão de nome .bmp) devem começar com as letras BMnos dois primeiros bytes. Os scripts na maioria das linguagens de script como Bash, Python, Perl, AWK etc. (basicamente tudo o que trata linhas que começam com #como comentário) podem conter um shebang #!/bin/bashcomo a primeira linha. Este comentário especial informa ao sistema com qual aplicativo abrir o arquivo.

Portanto, normalmente o sistema operacional depende do conteúdo do arquivo e não de seu nome para determinar o tipo de arquivo, mas afirmar que extensões de arquivo nunca são necessárias no Linux é apenas metade da verdade.

É claro que os aplicativos podem implementar suas verificações de arquivos da maneira que desejarem, o que inclui a verificação do nome e da extensão do arquivo. Um exemplo é o Eye of Gnome ( eogvisualizador de imagens padrão) que determina o formato da imagem pela extensão do arquivo e gera um erro se não corresponder ao conteúdo. Se isso é um bug ou um recurso pode ser discutido ...

No entanto, mesmo algumas partes do sistema operacional contam com extensões de nome de arquivo, por exemplo, ao analisar os arquivos de origem do software, /etc/apt/sources.list.d/apenas os arquivos com a *.listextensão são analisados e todos os outros são ignorados. Talvez não seja usado principalmente para determinar o tipo de arquivo aqui, mas para ativar / desativar a análise de alguns arquivos, mas ainda é uma extensão que afeta a maneira como o sistema trata um arquivo.

E, claro, os lucros usuário humano máximo de extensões de arquivo como que faz com que o tipo de um arquivo óbvio e também permite que vários arquivos com o mesmo nome de base e diferentes extensões como site.html, site.php, site.js, site.cssetc. A desvantagem é, naturalmente, que a extensão de arquivo e o real o tipo / conteúdo do arquivo não precisa necessariamente corresponder.

Além disso, é necessário para interoperabilidade entre plataformas, como por exemplo, o Windows não saberá o que fazer com um readmearquivo, mas apenas um readme.txt.

— Byte Commander
fonte

Você se contradiz um pouco aqui: se o visualizador de imagens padrão exigir um nome de arquivo que termine com .bmp, que parte do sistema operacional você diz depender do conteúdo do arquivo que inicia "BM"? AFAIK, os únicos "números mágicos do kernel se preocupa são tipos de executáveis, incluindo o caso especial de #!Tudo o resto é até a decisão de algum aplicativo..

— IMSOP

@IMSoP Eu não sei a implementação exata do eoge eu não sei por que eles se preocupam com o nome do arquivo em tudo. Este é um erro na minha opinião. E, é claro, se o arquivo for nomeado "bmp", mas seu formato de conteúdo não corresponder, também haverá um erro, é claro. É claro que cada aplicativo decide como verificar os arquivos, mas, em geral, os aplicativos Linux não devem confiar no nome. Aliás, você pode usar o fileelogio para examinar os tipos de arquivo pelo seu conteúdo.

— Byte Commander

11

A frase que estou desafiando é a seguinte: "Linux ... determina o tipo de arquivo examinando os primeiros bytes". Qual definição de "Linux" você está usando nessa frase? A existência do fileutilitário realmente não prova nada; é uma ferramenta útil, que poderia existir em qualquer sistema operacional. Que parte fundamental do sistema operacional torna a execução filemais "correta" do que globbing no nome do arquivo?

— 27716 IMSoP

Observe que arquivos sem extensão podem ser associados a um programa.

— Isanae 28/07

24

Conforme mencionado por outros, no Linux, um método de diretiva de intérprete é usado (armazenando alguns metadados em um arquivo como um cabeçalho ou número mágico, para que o intérprete correto seja instruído a lê-lo), em vez do método de associação de extensão de nome de arquivo usado pelo Windows.

Isso significa que você pode criar um arquivo com quase qualquer nome que desejar ... com algumas exceções

Contudo

Gostaria de acrescentar uma palavra de cautela.

Se você tiver alguns arquivos no sistema de um sistema que usa associação de nome de arquivo, os arquivos podem não ter esses números mágicos ou cabeçalhos. As extensões de nome de arquivo são usadas para identificar esses arquivos por aplicativos capazes de lê-los, e você poderá experimentar alguns efeitos inesperados se renomear esses arquivos. Por exemplo:

Se você renomear um arquivo My Novel.docpara My-Novel, o Libreoffice ainda poderá abri-lo, mas será aberto como 'Sem título' e você precisará nomeá-lo novamente para salvá-lo (o Libreoffice adiciona uma extensão por padrão, então você terá dois arquivos My-Novele My-Novel.odt, o que pode ser irritante)

Mais seriamente, se você renomear um arquivo My Spreadsheet.xlsx para My-Spreadsheet, tente abri-lo e xdg-open My-Spreadsheetvocê obterá isso (porque na verdade é um arquivo compactado):

E se você renomear um arquivo My Spreadsheet.xlspara My-Spreadsheet, quando xdg-open My-Spreadsheetreceber um erro dizendo

erro ao abrir o local: nenhum aplicativo está registrado como manipulando este arquivo

(Embora em ambos os casos funcione bem se você o fizer soffice My-Spreadsheet)

Se você renomear o arquivo sem extensão para My-Spreadsheet.odswith mve tentar abri-lo, obterá o seguinte:

(falha no reparo)

E você terá que colocar a extensão original novamente para abrir o arquivo corretamente (você pode converter o formato, se desejar)

TL; DR:

Se você tiver arquivos não nativos com extensões de nome, não remova as extensões assumindo que tudo ficará bem!

— Zanna
fonte

4

Um documento novo do MS Office (docx, xlsx, pptx etc) sem extensão de arquivo é aberto no gerenciador de arquivamento porque esses tipos de arquivos são na verdade apenas arquivos compactados ZIP comuns que contêm todos os documentos XML e arquivos de mídia necessários para definir o conteúdo do documento. O formato de arquivo de um diretório compactado ZIP é bastante comum hoje em dia.

— Byte Commander

11

Já existem muitas ótimas respostas, mas apenas mais uma específica do libreoffice que eu notei. Você cria um arquivo de valores separados por vírgula (CSV) e o salva como "test.csv", uma janela será aberta perguntando que tipo de separador você está usando (por exemplo, libreoffice Calc). Se você renomear esse arquivo como "test.cs", por exemplo, o Writer do libreoffice o abrirá. Portanto, além do exemplo ZIP acima, parece que o libreoffice faz uso da extensão do arquivo.

— Raio

3

O sistema de arquivos linux não faz nada em relação aos tipos de arquivo. Isso tudo depende dos programas executados em cima dele.

— Peter Green

@PeterGreen Sim, mas o fato de os programas atribuírem significado a isso significa que não é "apenas para os seres humanos" da maneira como, por exemplo, o MacOS clássico tinha [havia campos de quatro bytes "tipo de arquivo" e "aplicativo criador" que não eram ' t parte do nome do arquivo, de modo que o sistema operacional e aplicativos tinha todas as informações que precisavam sem olhar para extensões de arquivos]

— Random832

3

@PeterGreen O sistema de arquivos do Windows também não faz nada em relação aos tipos de arquivo. O shell gráfico (Windows Explorer) usa a extensão de arquivo para escolher uma ação para clicar duas vezes, mas tecnicamente é apenas um programa em execução no topo do sistema operacional, assim como o Nautilus. Seria perfeitamente possível escrever um gerenciador de arquivos Linux com esse comportamento ou um Windows que examinasse o conteúdo do arquivo.

— IMSoP 27/07

20

Eu gostaria de ter uma abordagem diferente para isso de outras respostas e desafiar a noção de que "Linux" ou "Windows" têm algo a ver com isso (tenha paciência comigo).

O conceito de extensão de arquivo pode ser simplesmente expresso como "uma convenção para identificar o tipo de arquivo com base em parte de seu nome". As outras convenções comuns para identificar o tipo de um arquivo estão comparando seu conteúdo com um banco de dados de assinaturas conhecidas (a abordagem "número mágico") e armazenando-o como um atributo extra no sistema de arquivos (a abordagem usada no MacOS original) .

Como todo arquivo em um sistema Windows ou Linux possui um nome e um conteúdo, os processos que desejam conhecer o tipo de arquivo podem usar as abordagens "extensão" ou "número mágico", conforme entenderem. A abordagem de metadados geralmente não está disponível, pois não há um local padrão para esse atributo na maioria dos sistemas de arquivos.

No Windows, existe uma forte tradição de usar a extensão de arquivo como o principal meio de identificar um arquivo; de maneira mais visível, o navegador de arquivos gráficos (Gerenciador de Arquivos no Windows 3.1 e Explorer no Windows moderno) o utiliza quando você clica duas vezes em um arquivo para determinar qual aplicativo iniciar. No Linux (e, geralmente, em sistemas baseados em Unix), há mais tradição para inspecionar o conteúdo; mais notavelmente, o kernel examina o início de um arquivo executado diretamente para determinar como executá-lo; os arquivos de script podem indicar um intérprete a ser usado, iniciando com #!seguido pelo caminho para o intérprete.

Essas tradições influenciam o design da interface do usuário dos programas escritos para cada sistema, mas há muitas exceções, porque cada abordagem tem prós e contras em diferentes situações. Os motivos para usar extensões de arquivo em vez de examinar o conteúdo incluem:

examinar o conteúdo do arquivo é bastante caro comparado ao exame dos nomes dos arquivos; portanto, por exemplo, "encontre todos os arquivos denominados * .conf" será muito mais rápido que "encontre todos os arquivos cuja primeira linha corresponda a esta assinatura"
o conteúdo do arquivo pode ser ambíguo; na verdade, muitos formatos de arquivo são apenas arquivos de texto tratados de uma maneira especial, muitos outros são arquivos zip especialmente estruturados e definir assinaturas precisas para eles pode ser complicado
um arquivo pode realmente ser válido como mais de um tipo; um arquivo HTML também pode ser XML válido, um arquivo zip e um GIF concatenados juntos permanecem válidos para ambos os formatos
a correspondência de números mágicos pode levar a falsos positivos; um formato de arquivo sem cabeçalho pode começar com os bytes "GIF89a" e ser identificado incorretamente como uma imagem GIF
renomear um arquivo pode ser uma maneira conveniente de marcá-lo como "desativado"; por exemplo, alterar "foo.conf" para "foo.conf ~" para indicar um backup é mais fácil do que editar o arquivo para comentar todas as suas diretivas e mais conveniente do que movê-lo para fora de um diretório carregado automaticamente; Da mesma forma, renomear um arquivo .php para .txt instruirá o Apache a servir sua fonte como texto sem formatação, em vez de passá-lo para o mecanismo PHP

Exemplos de programas Linux que usam nomes de arquivos por padrão (mas podem ter outros modos):

O gzip e o gunzip têm tratamento especial de qualquer arquivo que termine ".gz"
O gcc manipulará arquivos ".c" como C e ".cc" ou ".C" como C ++

— IMSoP
fonte

O Windows também tem uma forte tradição de ocultar a extensão se ela é "conhecida" e até o DOS permitiu que um comando omitisse .COM, .BAT e .EXE, procurando automaticamente por aqueles para determinar qual programa real executar. Não existe tal tradição em * nix.

— Monty mais dura

Essa é uma resposta muito melhor, mas tem um erro de fato ... um script não pode ser executável colocando #!-o no início. Qualquer arquivo com seu conjunto de bits executáveis pode ser executado de uma de várias maneiras. #!/bin/bashe assinaturas semelhantes apenas especificam qual intérprete usar. Se nenhuma assinatura for fornecida, o interpretador de shell padrão será assumido. Um arquivo contendo nada além das duas palavras 'Hello World', mas com o bit de execução definido, tentará encontrar um comando 'Hello' quando executado.

— DocSalvager 2/08/16

11

@DocSalvager Boa pegada, essa era uma expressão desajeitada tanto quanto qualquer outra coisa. Eu reformulei um pouco para deixar claro que o shebang não torna o script executável, apenas muda a forma como ele é executado.

— IMSoP 02/08

15

Na verdade, algumas tecnologias que dependem de extensões de arquivos, então se você usar essas tecnologias em Ubuntu, você tem que confiar em extensões também. Alguns exemplos:

gccusa extensões para distinguir entre arquivos C e C ++. Sem a extensão, é praticamente impossível diferenciá-las (imagine um arquivo C ++ sem classes).
muitos arquivos ( docx, jar, apk) estão apenas particularmente estruturado arquivos ZIP. Embora você normalmente possa inferir o tipo do conteúdo, nem sempre isso é possível (por exemplo, o Java Manifest é opcional nos jararquivos).

O não uso de extensões de arquivo nesses casos só será possível com soluções alternativas de hackers e provavelmente será muito propenso a erros.

— Dmitry Grigoryev
fonte

Bom em você por mencionar a programação, mas você errou a maioria dos detalhes. gccé o front-end para arquivos C; para arquivos C ++, é necessário o g++front-end ou uma opção de linha de comando para especificar o idioma. Mais importante é o makeprograma que decide se deve usar gccou g++criar um arquivo específico - e makeé completamente dependente dos padrões de nome de arquivo (principalmente extensões) para sua correspondência de regras.

— Ben Voigt

@BenVoigt Ao compilar um arquivo com uma .ccextensão gcc, ele realmente será compilado como C ++, e isso está documentado em man gcc: "Para qualquer arquivo de entrada, o sufixo do nome do arquivo determina que tipo de compilação é feita:" seguido por uma lista de extensões e como elas são tratadas.

— hvd 30/07

11

@hvd Então talvez seja o conjunto padrão de bibliotecas que dá terrivelmente errado se você não usar o front end correto. De qualquer forma, make é o principal exemplo, porque tudo o que faz é baseado na extensão do arquivo.

— Ben Voigt

11

O @BenVoigt também makeé um bom exemplo, mas gccdepende muito dos nomes de arquivos. Aqui está um exemplo mais claro que .cvs .cc: para C, gccusa sufixos para dizer se o primeiro passo é pré-processar ( .c), compilar ( .i), montar ( .s) ou vincular ( .o). Aqui, eu uso -E, -Se -cpara dizer gcconde parar , mas ele usa nomes de arquivos para saber onde começar . gcc something.ccnão vão ligar para as bibliotecas certas para C ++, mas ele vai tratar o arquivo como C ++, que é por isso que muitos usuários estão confusos com as mensagens de erro que recebem ao fazer esse erro.

— Eliah Kagan

7

Sua primeira suposição está correta: as extensões no Linux não importam e são úteis apenas para humanos (e para outros SOs não semelhantes ao Unix que se preocupam com extensões). O tipo de um arquivo é determinado pelos primeiros 32 bits de dados no arquivo, conhecido como número mágico. É por isso que os scripts de shell precisam de #!linha - para informar ao sistema operacional qual intérprete chamar. Sem ele, o shell script é apenas um arquivo de texto.

No que diz respeito aos gerenciadores de arquivos, eles querem conhecer extensões de alguns arquivos, como .desktoparquivos, que são basicamente os mesmos da versão de atalhos do Windows, mas com mais recursos. Mas, no que diz respeito ao sistema operacional, ele precisa saber o que está no arquivo, não o que está em seu nome

— Sergiy Kolodyazhnyy
fonte

3

Isso não é bem verdade. Existem programas que esperam uma extensão específica. O exemplo mais comumente usado é provavelmente o gunzipque não descompacta um arquivo se não for chamado foo.gz.

— terdon

Essa é uma implementação de software específico. Na maioria das vezes, os utilitários em sistemas tipo unix não esperam uma extensão.

— Sergiy Kolodyazhnyy

7

Na maioria das vezes não, não. Sua primeira frase, no entanto, afirma que eles nunca são usados e são importantes apenas para os seres humanos. Isso não é inteiramente verdade. gunzipé um exemplo, eogé outro. Além disso, muitas ferramentas não completam automaticamente os nomes sem a extensão correta. Tudo o que estou dizendo é que é um pouco mais complicado do que "extensões são sempre irrelevantes".

— terdon

11

1 pequeno problema: OP perguntou sobre o sistema operacional. 'gunzip' e 'eog' não são o sistema operacional, mas decidiram criar suas próprias restrições (no caso de gunzip) ou método (eog). "tipos de mímica" embora.

— Rinzwind 27/07

11

@Serg Claro, você pode definir o SO de maneira restrita e obter uma resposta trivial à pergunta. Porém, não é uma resposta particularmente útil, porque a grande maioria do que um usuário faz com um computador envolve software que você excluiu. Observe que a pergunta contrastava "apenas para humanos" contra "o sistema operacional"; Eu não acho que eles queriam dizer "o kernel".

— IMSoP 29/07

6

Isso é muito grande para uma resposta de comentário.

Lembre-se de que mesmo "extensão" tem muitos significados diferentes.

O que você está falando parece ser as três letras após o. O DOS tornou o formato 8.3 muito popular e o Windows usa a parte .3 até hoje.

O Linux tem muitos arquivos como .conf ou .list ou .d ou .c que têm significado, mas não são realmente extensões no sentido 8.3. Por exemplo, o Apache observa /etc/apache2/sites-enabled/website.conf a sua diretiva de configuração. Enquanto o sistema usa tipos MIME e cabeçalhos de conteúdo e o que não determinar, é um arquivo de texto, mas o Apache (por padrão) ainda não o carregará sem terminar em .conf.

.c é outro ótimo. Sim, é um arquivo de texto, mas o gcc depende de main.c se tornar main.o e finalmente main (após o link). Em nenhum momento o sistema usa a extensão .c, .o ou nenhuma extensão para ter algum significado no que diz respeito ao conteúdo, mas as coisas após a. tem algum significado. Você provavelmente configuraria seu SCM para ignorar main.o e main.

O ponto principal é o seguinte: as extensões não são usadas como são nas janelas. O kernel não executará um arquivo .txt porque você remove a parte .txt do nome. Também é muito prazer executar um arquivo .txt se a permissão de execução estiver definida. Dito isto, eles têm significado e ainda são usados no "nível do computador" para muitas coisas.

— coteyr
fonte

11

Windows também não está vinculada ao x.3esquema de nomenclatura todas as extensões mais longas mais, você tem lá, bem como .doxc, .torrent, .part, etc. É que muitos formatos de arquivo e extensões foram já definidas para trás no momento em que nomes 8.3 ainda era uma coisa e depois os formatos simplesmente adaptaram a convenção de usar até 3 letras.

— Byte Commander

Não vejo como ".conf", ".c" etc. são "um significado diferente" do "sentido 8.3". O conceito de extensão de arquivo pode ser simplesmente expresso como "uma convenção para identificar o tipo de arquivo com base em parte de seu nome". Nem o DOS / Win3.1 exigiu a extensão correta (você pode chamar um documento do Word "STUPIDN.AME" e abri-lo com Ctrl-O no WinWord). É só que alguns sistemas (por exemplo, clique duas vezes no Windows, em gzipseu Makefile etc.) podem ser escritos para usar esta convenção para fazer suposições sobre a ação correta a ser executada em cada arquivo.

— IMSoP 27/07/16

@ByteCommander Isso é verdade, mas a extensão ainda determina o aplicativo usado. Não sei como editar a resposta para refletir isso.

— coteyr

11

@coteyr Novamente, tudo depende do que queremos dizer com "o SO". O Gerenciador de Arquivos certamente procurará uma chave de registro para "AME" e dirá que "foo.txt" é um arquivo de texto. Mas rodar direm um prompt de comando não me diz nada disso; simplesmente não se importa. A execução de arquivos é certamente uma exceção nos dois sistemas operacionais; se a pergunta fosse limitada a eles, a resposta seria que o DOS / Windows se preocupa apenas com o nome e o Unix / Linux se importa apenas com a permissão de execução e os primeiros bytes do arquivo. Fora isso, sempre há algum aplicativo que escolhe uma convenção a seguir.

— 27416 IMSoP

11

@coteyr Você esqueceu * .scr (binário no protetor de tela) no Windows 3.1 e superior. Dito isto, a extensão do arquivo, mesmo nos sistemas DOS / Windows, mesmo para executáveis, ainda é apenas uma conveniência. As especificidades dependem muito de onde você desenha a linha do "sistema operacional", mas você sempre pode carregar um binário na memória e pular nela, executando o trabalho que normalmente é solicitado ao sistema operacional. No MS-DOS, se você consultar o command.com, tenho certeza de que há uma lista como EXE COM que você pode editar para procurar outras extensões se nenhuma for especificada (sem dizer que seria uma boa ideia, preste atenção).

— um CVn