¿Las extensiones de archivo tienen algún propósito (para el sistema operativo)?

73

Linux determina el tipo de archivo a través de un código en el encabezado del archivo. No depende de las extensiones de archivo para saber qué software se utilizará para abrir el archivo.

Eso es lo que recuerdo de mi educación. ¡Corrígeme en caso de que me equivoque!

Trabajar un poco con los sistemas de Ubuntu recientemente: Veo una gran cantidad de archivos en los sistemas que tienen extensiones como .sh, .txt, .o,.c

Ahora me pregunto: ¿Estas extensiones son solo para humanos? ¿Para que uno tenga una idea de qué tipo de archivo es?

¿O también tienen algún propósito para el sistema operativo?

files file-format mime-type

— mizech
fuente

55

Si no obtiene una buena respuesta aquí, recuerde que también hay unix.stackexchange.com

— mchid

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

— Zzzach ...

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

— caos

55

En Windows lo hacen, en Linux / Unix en su mayoría no. La principal excepción son los programas de compresión-- gzip, bzip2, xz- y así sucesivamente. Estos programas usan sufijos para separar la versión comprimida de un archivo de la versión sin comprimir que reemplazan. Los programas de compresión a menudo se quejan de sufijos incorrectos, aunque el archivo en realidad es un archivo comprimido del tipo que debería manejar.

— Baard Kopperud

66

Creo que parte del problema con esta pregunta es que "el sistema operativo" no es un concepto bien definido. ¿Qué es parte del sistema operativo y qué es una aplicación sobre él? No muchas partes del sistema operativo (del sistema operativo del que estamos hablando) se preocupan por el tipo de archivo, simplemente hacen lo que se les dice. Entonces las distinciones sobre cómo saben son irrelevantes; ellos tampoco. Las aplicaciones, por otro lado, bien pueden hacer una o ambas cosas.

— IMSoP

39

Linux determina el tipo de archivo a través de un código en el encabezado del archivo. No depende de las extensiones de archivo para saber con el software que se utilizará para abrir el archivo.

Eso es lo que recuerdo de mi educación. ¡Corrígeme en caso de que me equivoque!

correctamente recordado

¿Estas extensiones son solo para humanos?

Sí, con un pero.

Cuando interactúa con otros sistemas operativos que dependen de que las extensiones sean lo que son, es la idea más inteligente usarlos.

En Windows, el software de apertura se adjunta a las extensiones.

La apertura de un archivo de texto llamado "archivo" es más duro en Windows de abrir el mismo archivo llamado "archivo.txt" (que tendrá que cambiar el diálogo de abrir archivo desde *.txtque *.*cada vez). Lo mismo ocurre con los archivos de texto separados por TAB y punto y coma. Lo mismo ocurre con la importación y exportación de correos electrónicos (extensión .mbox).

En particular cuando codificas software. Abrir un archivo llamado "software1" que es un archivo HTML y "software2" que es un archivo JavaScript se vuelve más difícil en comparación con "software.html" y "software.js".

Si hay un sistema en Linux donde las extensiones de archivo son importantes, lo llamaría un error. Cuando el software depende de las extensiones de archivo, eso es explotable. Utilizamos una directiva de intérprete para identificar qué es un archivo ("los primeros dos bytes en un archivo pueden ser los caracteres" #! ", Que constituyen un número mágico (hexadecimal 23 y 21, los valores ASCII de" # "y"! ") a menudo denominado shebang,").

El problema más famoso con las extensiones de archivo fue LOVE-LETTER-FOR-YOU.TXT.vbs en Windows. Este es un script visual básico que se muestra en el explorador de archivos como un archivo de texto.

En Ubuntu cuando inicia un archivo desde Nautilus, recibe una advertencia de lo que va a hacer. Ejecutar un script desde Nautilus donde quiere iniciar algún software donde se supone que debe abrir gEdit es un problema obvio y recibimos una advertencia al respecto.

En la línea de comando cuando ejecuta algo, puede ver visualmente cuál es la extensión. Si termina en .vbs, comenzaría a sospechar (no es que .vbs sea ejecutable en Linux. Al menos no sin un poco más de esfuerzo;)).

— Rinzwind
fuente

31

No entiendo completamente lo que querías decir en tu última oración. Primero, es un problema de ocultar la extensión en lugar de tenerla; segundo, el exploit funcionaría igual en Linux: usted nombra un archivo binario readme.txty lo hace ejecutable. Si el usuario lo ejecutó, no abre el editor, pero ejecuta el código. En este sentido, hacer que las extensiones importen (pero no ocultarlas) es más seguro y más fácil de explicar para los usuarios no conocedores. Existen otras diferencias (sobre todo no ejecutar archivos desde el directorio actual), pero no tienen nada que ver con las extensiones.

— techraf

44

@techraf En realidad, el administrador de archivos probablemente intentará abrir el readme.txtarchivo con un editor de texto. Acabo de probar con dolphin en KDE, creando un script de shell que agrega permiso ejecutable, guardándolo como .txty haciendo clic en él lo abrirá en Kate. Si le cambio el nombre, .shentonces al hacer clic en él lo ejecuta.

— Bakuriu

9

linux: dado que make se basa en reglas que dependen de la extensión del archivo, ¿no sería make (sin juego de palabras) las extensiones destinadas a algo más que humanos?

— bolov

15

Esta es una respuesta monumentalmente incorrecta. Algunas partes de Linux usan números mágicos para determinar los tipos de archivos. Ejecutando archivos en la línea de comando. Pero otras partes enormes del sistema usan extensiones de archivo para saber qué mirar, ya sea el enlazador dinámico (que quiere archivos .so), modprobe, sistemas de compilación, complementos, bibliotecas para python, ruby, etc. Muchos archivos no ' No tiene números mágicos, fileestá basado en heurística, no está definido.

— Alan Shutko

3

"Linux determina el tipo de archivo a través de un código en el encabezado del archivo" "correcto" WTF? ¿Qué "código en el encabezado del archivo"? No existe dicho código, y no existe un "encabezado de archivo" genérico en Linux.

— leonbloy

68

No hay una respuesta 100% en blanco o negro aquí.

Por lo general, Linux no se basa en nombres de archivo (y extensiones de archivo, es decir, la parte del nombre del archivo después del último período normalmente) y en su lugar determina el tipo de archivo examinando los primeros bytes de su contenido y comparándolo con una lista de números mágicos conocidos .

Por ejemplo, todos los archivos de imagen de mapa de bits (generalmente con extensión de nombre .bmp) deben comenzar con las letras BMen sus dos primeros bytes. Las secuencias de comandos en la mayoría de los lenguajes de secuencias de comandos como Bash, Python, Perl, AWK, etc. (básicamente todo lo que trata las líneas que comienzan con un #comentario) pueden contener un shebang #!/bin/bashcomo primera línea. Este comentario especial le dice al sistema con qué aplicación abrir el archivo.

Entonces, normalmente el sistema operativo se basa en el contenido del archivo y no en su nombre para determinar el tipo de archivo, pero declarar que las extensiones de archivo nunca son necesarias en Linux es solo la mitad de la verdad.

Por supuesto, las aplicaciones pueden implementar sus comprobaciones de archivos como quieran, lo que incluye verificar el nombre y la extensión del archivo. Un ejemplo es el Eye of Gnome ( eogvisor de imágenes estándar) que determina el formato de imagen por la extensión del archivo y genera un error si no coincide con el contenido. Se puede discutir si esto es un error o una característica ...

Sin embargo, incluso algunas partes del sistema operativo dependen de las extensiones de nombre de archivo, por ejemplo, al analizar los archivos de origen de su software /etc/apt/sources.list.d/, solo los archivos con la *.listextensión se analizan; todos los demás se ignoran. Quizás no se usa principalmente para determinar el tipo de archivo aquí, sino para habilitar / deshabilitar el análisis de algunos archivos, pero sigue siendo una extensión de archivo que afecta la forma en que el sistema trata un archivo.

Y, por supuesto, los beneficios de los usuarios humanos más de extensiones de archivo que eso hace que el tipo de un archivo obvio y también permite que varios archivos con el mismo nombre base y diferentes extensiones como site.html, site.php, site.js, site.cssextensión, etc. La desventaja es, por supuesto, ese archivo y lo actual el tipo / contenido de archivo no necesariamente tiene que coincidir.

Además, es necesario para la interoperabilidad entre plataformas, ya que, por ejemplo, Windows no sabrá qué hacer con un readmearchivo, sino solo a readme.txt.

— Byte Commander
fuente

Aquí se contradice un poco: si el visor de imágenes estándar requiere un nombre de archivo que termine en .bmp, ¿qué parte del sistema operativo dice que depende del contenido del archivo que comienza con "BM"? AFAIK, los únicos "números mágicos que le importan al kernel son los tipos ejecutables, incluido el caso especial #!. Todo lo demás depende de la decisión de algunas aplicaciones."

— IMSoP

@IMSoP No sé la implementación exacta eogy no sé por qué les importa el nombre del archivo. Esto es un error en mi opinión. Y, por supuesto, si el archivo se llama "bmp" pero su formato de contenido no coincide, también habrá un error, por supuesto. Por supuesto, cada aplicación decide cómo verificar los archivos, pero en general las aplicaciones de Linux no deberían depender del nombre. Por cierto, puede usar la filerecomendación para examinar los tipos de archivo por su contenido.

— Byte Commander

1

La frase que estoy desafiando es esta: "Linux ... determina el tipo de archivo al examinar los primeros bytes". ¿Qué definición de "Linux" estás usando en esa oración? La existencia de la fileutilidad realmente no prueba nada; Es una herramienta útil, que podría existir en cualquier sistema operativo. ¿Qué parte fundamental del sistema operativo hace que la ejecución filesea más "correcta" que bloquear el nombre del archivo?

— IMSoP

Tenga en cuenta que los archivos sin extensión se pueden asociar a un programa.

— isanae

24

Como mencionan otros, en Linux se usa un método de directiva de intérprete (almacenar algunos metadatos en un archivo como encabezado o número mágico para que se le diga al intérprete correcto que lo lea) en lugar del método de asociación de extensión de nombre de archivo utilizado por Windows.

Esto significa que puede crear un archivo con casi cualquier nombre que desee ... con algunas excepciones

sin embargo

Me gustaría agregar una palabra de precaución.

Si tiene algunos archivos en su sistema de un sistema que usa asociación de nombre de archivo, es posible que los archivos no tengan esos números mágicos o encabezados. Las extensiones de nombre de archivo se usan para identificar estos archivos por aplicaciones que pueden leerlos, y puede experimentar algunos efectos inesperados si cambia el nombre de dichos archivos. Por ejemplo:

Si cambia el nombre de un archivo My Novel.doca My-Novel, Libreoffice aún podrá abrirlo, pero se abrirá como 'Sin título' y tendrá que volver a nombrarlo para guardarlo (Libreoffice agrega una extensión de forma predeterminada, por lo que entonces tendrá dos archivos My-Novely My-Novel.odt, lo que podría ser molesto)

Más en serio, si cambia el nombre de un archivo My Spreadsheet.xlsx a My-Spreadsheet, intente abrirlo y xdg-open My-Spreadsheetobtendrá esto (porque en realidad es un archivo comprimido):

Y si cambia el nombre de un archivo My Spreadsheet.xlsa My-Spreadsheet, cuando xdg-open My-Spreadsheetrecibe un error que dice

error al abrir la ubicación: no hay ninguna aplicación registrada que maneje este archivo

(Aunque en ambos casos funciona bien si lo haces soffice My-Spreadsheet)

Si a continuación, cambia el nombre del archivo sin extensión a My-Spreadsheet.odsla mve intenta abrirlo obtendrá la siguiente:

(la reparación falla)

Y tendrá que volver a colocar la extensión original para abrir el archivo correctamente (luego puede convertir el formato si lo desea)

TL; DR:

Si tiene archivos no nativos con extensiones de nombre, ¡no elimine las extensiones suponiendo que todo estará bien!

— Zanna
fuente

44

Un documento de MS Office de nuevo estilo (docx, xlsx, pptx, etc.) sin extensión de archivo se abre en el administrador de archivos porque esos tipos de archivos en realidad son archivos comprimidos ZIP normales que contienen todos los documentos XML y archivos multimedia necesarios para definir el contenido del documento. El formato de archivo de un directorio comprimido ZIP es bastante común hoy en día por cierto.

— Byte Commander

1

Ya tengo muchas respuestas geniales, pero solo una más específica para libreoffice que he notado. Si crea un archivo de valores separados por comas (CSV) y lo guarda como "test.csv", se abrirá una ventana preguntando qué tipo de separador está utilizando (es decir, libreoffice Calc). Si cambia el nombre de este archivo a "test.cs", por ejemplo, entonces el escritor de libreoffice lo abre. Entonces, además del ejemplo ZIP anterior, parece que libreoffice hace uso de la extensión de archivo.

— Ray

3

El sistema de archivos de Linux no hace nada con respecto a los tipos de archivos. Todo se debe a los programas que se ejecutan encima.

— Peter Green

@PeterGreen Sí, pero el hecho de que los programas le asignen importancia significa que no es "solo para humanos" como, por ejemplo, MacOS clásico lo tenía [había cuatro campos de "tipo de archivo" y "aplicación creadora" de cuatro bytes. t parte del nombre del archivo, por lo que el sistema operativo y las aplicaciones tenían toda la información que necesitaban sin mirar las extensiones de archivo]

— Random832

3

@PeterGreen El sistema de archivos de Windows tampoco hace nada con respecto a los tipos de archivos. El shell gráfico (Windows Explorer) usa la extensión de archivo para elegir una acción para hacer doble clic, pero técnicamente es solo un programa que se ejecuta en la parte superior del sistema operativo, al igual que Nautilus. Sería perfectamente posible escribir un administrador de archivos de Linux con ese comportamiento, o uno de Windows que examinara el contenido del archivo.

— IMSoP

20

Me gustaría adoptar un enfoque diferente de otras respuestas, y desafiar la noción de que "Linux" o "Windows" tienen algo que ver con esto (tengan paciencia conmigo).

El concepto de una extensión de archivo puede expresarse simplemente como "una convención para identificar el tipo de archivo basado en parte de su nombre". Las otras convenciones comunes para identificar el tipo de archivo son comparar su contenido con una base de datos de firmas conocidas (el enfoque de "número mágico") y almacenarlo como un atributo adicional en el sistema de archivos (el enfoque utilizado en el MacOS original) .

Dado que cada archivo en un sistema Windows o Linux tiene tanto un nombre como contenido, los procesos que desean conocer el tipo de archivo pueden usar los enfoques de "extensión" o "número mágico" como lo consideren conveniente. El enfoque de metadatos generalmente no está disponible, ya que no existe un lugar estándar para este atributo en la mayoría de los sistemas de archivos.

En Windows, existe una fuerte tradición de usar la extensión de archivo como el medio principal para identificar un archivo; Lo más visible es que el explorador de archivos gráficos (Administrador de archivos en Windows 3.1 y Explorer en Windows moderno) lo utiliza cuando hace doble clic en un archivo para determinar qué aplicación iniciar. En Linux (y, más generalmente, sistemas basados en Unix), hay más tradición para inspeccionar los contenidos; más notablemente, el núcleo mira al principio de un archivo ejecutado directamente para determinar cómo ejecutarlo; los archivos de script pueden indicar un intérprete para usar comenzando por #!seguido de la ruta al intérprete.

Estas tradiciones influyen en el diseño de la interfaz de usuario de los programas escritos para cada sistema, pero hay muchas excepciones, porque cada enfoque tiene ventajas y desventajas en diferentes situaciones. Las razones para usar extensiones de archivo en lugar de examinar los contenidos incluyen:

examinar el contenido del archivo es bastante costoso en comparación con examinar los nombres de los archivos; por ejemplo, "buscar todos los archivos llamados * .conf" será mucho más rápido que "buscar todos los archivos cuya primera línea coincida con esta firma"
el contenido del archivo puede ser ambiguo; muchos formatos de archivo son en realidad solo archivos de texto tratados de una manera especial, muchos otros son archivos zip especialmente estructurados, y definir firmas precisas para estos puede ser complicado
un archivo puede ser realmente válido como más de un tipo; un archivo HTML también puede ser XML válido, un archivo zip y un GIF concatenados juntos siguen siendo válidos para ambos formatos
la coincidencia de números mágicos puede conducir a falsos positivos; un formato de archivo que no tiene encabezado puede comenzar con los bytes "GIF89a" y ser identificado erróneamente como una imagen GIF
cambiar el nombre de un archivo puede ser una forma conveniente de marcarlo como "deshabilitado"; por ejemplo, cambiar "foo.conf" a "foo.conf ~" para indicar que una copia de seguridad es más fácil que editar el archivo para comentar todas sus directivas, y más conveniente que sacarlo de un directorio cargado automáticamente; Del mismo modo, cambiar el nombre de un archivo .php a .txt le indicará a Apache que sirva su fuente como texto sin formato, en lugar de pasarlo al motor PHP

Ejemplos de programas de Linux que usan nombres de archivos de forma predeterminada (pero pueden tener otros modos):

gzip y gunzip tienen un manejo especial de cualquier archivo que termine ".gz"
gcc manejará archivos ".c" como C, y ".cc" o ".C" como C ++

— IMSoP
fuente

Windows también tiene una fuerte tradición de ocultar la extensión si es "bien conocida" e incluso DOS permitió que un comando omitiera .COM, .BAT y .EXE, buscando automáticamente aquellos para determinar qué programa real ejecutar. No existe tal tradición en * nix.

— Monty Harder

Esta es una respuesta mucho mejor, pero tiene un error de hecho ... un script no se puede hacer ejecutable al colocarlo #!al principio. Cualquier archivo con su conjunto de bits ejecutables puede ejecutarse de una de varias maneras. #!/bin/bashy firmas similares solo especifican qué intérprete usar. Si no se proporciona dicha firma, se supone el intérprete de shell predeterminado. Un archivo que no contenga más que las dos palabras 'Hola Mundo', pero con su bit de ejecución establecido, intentará encontrar un comando 'Hola' cuando se ejecute.

— DocSalvager

1

@DocSalvager Buena captura, esa fue una redacción torpe tanto como cualquier otra cosa. Lo reformulé un poco para dejar en claro que el shebang no hace que el script sea ejecutable, solo cambia la forma en que se ejecuta.

— IMSoP

15

En realidad, algunas tecnologías no depender de extensiones de archivo, así que si usa esas tecnologías en Ubuntu, tendrá que depender de extensiones también. Algunos ejemplos:

gccusa extensiones para distinguir entre archivos C y C ++. Sin la extensión es prácticamente imposible diferenciarlos (imagine un archivo C ++ sin clases).
muchos archivos ( docx, jar, apk) sólo están estructurados en especial archivos ZIP. Si bien generalmente puede inferir el tipo del contenido, puede que no siempre sea posible (por ejemplo, Java Manifest es opcional en los jararchivos).

No usar extensiones de archivo en tales casos solo será posible con soluciones alternativas y es probable que sea muy propenso a errores.

— Dmitry Grigoryev
fuente

Bien por mencionar la programación, pero te equivocaste en la mayoría de los detalles. gcces el front-end para archivos C, para archivos C ++ necesita el g++front-end o un interruptor de línea de comandos para especificar el idioma. Más importante es el makeprograma que decide si usar gcco g++construir un archivo en particular, y makedepende completamente de los patrones de nombre de archivo (principalmente extensiones) para su coincidencia de reglas.

— Ben Voigt

@BenVoigt Al compilar un archivo con una .ccextensión gcc, realmente se compilará como C ++, y esto se documenta en man gcc: "Para cualquier archivo de entrada dado, el sufijo del nombre de archivo determina qué tipo de compilación se realiza:" seguido de una lista de extensiones y cómo se tratan.

— hvd

1

@hvd Entonces, tal vez es el conjunto predeterminado de bibliotecas que sale terriblemente mal si no utiliza la interfaz correcta. De todos modos, make es el mejor ejemplo porque todo lo que hace se basa en la extensión del archivo.

— Ben Voigt

1

@BenVoigt también makees un buen ejemplo, pero gccdepende en gran medida de los nombres de archivo. Aquí hay un ejemplo más claro que .cvs .cc: para C, gccusa sufijos para saber si su primer paso es preprocesar ( .c), compilar ( .i), ensamblar ( .s) o enlazar ( .o). Aquí, yo uso -E, -Sy -cque le diga gccdónde parar , pero utiliza nombres de archivo que saber dónde comenzar . gcc something.ccNo se vinculará a las bibliotecas adecuadas para C ++ pero será tratar el archivo como C ++, por lo que muchos usuarios están confundidos por los mensajes de error que obtienen al hacer ese error.

— Eliah Kagan

7

Su primera suposición es correcta: las extensiones en Linux no importan y solo son útiles para los humanos (y otros sistemas operativos que no son de Unix que se preocupan por las extensiones). El tipo de un archivo está determinado por los primeros 32 bits de datos en el archivo, lo que se conoce como número mágico. Esta es la razón por la cual los scripts de shell necesitan #!línea, para indicarle al sistema operativo qué intérprete debe llamar. Sin él, el script de shell es solo un archivo de texto.

En lo que respecta a los administradores de archivos, quieren conocer las extensiones de algunos archivos, como los .desktoparchivos, que básicamente son lo mismo que la versión de Windows de los accesos directos, pero con más capacidades. Pero en lo que respecta al sistema operativo, necesita saber qué hay en el archivo, no qué hay en su nombre.

— Sergiy Kolodyazhnyy
fuente

3

Esto no es del todo cierto. Hay programas que esperan una extensión específica. El ejemplo más utilizado es probablemente el gunzipque no descomprimirá un archivo si no se llama foo.gz.

— terdon

Esa es una implementación de software específico. En su mayor parte, las utilidades en sistemas tipo Unix no esperan una extensión.

— Sergiy Kolodyazhnyy

77

En su mayor parte no lo hacen, no. Sin embargo, su primera oración afirma que nunca se usan y solo son importantes para los humanos. Eso no es del todo cierto. gunzipEs un ejemplo, eoges otro. Además, muchas herramientas no completarán automáticamente los nombres sin la extensión correcta. Todo lo que digo es que es un poco más complicado que "las extensiones siempre son irrelevantes".

— terdon

1

1 pequeño problema: OP preguntó sobre el sistema operativo. 'gunzip' y 'eog' no son el sistema operativo, pero decidieron crear sus propias restricciones (en caso de gunzip) o método (eog). "tipos mimo" sin embargo.

— Rinzwind

1

@Serg Claro, puede definir el sistema operativo de forma limitada y obtener una respuesta trivial a la pregunta. Sin embargo, no es una respuesta particularmente útil, porque la gran mayoría de lo que un usuario hace con una computadora involucra software que usted ha excluido. Tenga en cuenta que la pregunta contrastaba "solo para humanos" con "el sistema operativo"; No creo que significaran "el núcleo".

— IMSoP

6

Esta es una respuesta demasiado grande para un comentario.

Tenga en cuenta que incluso "extensión" tiene muchos significados diferentes.

De lo que estás hablando parecen ser las 3 letras después del. DOS hizo que el formato 8.3 fuera realmente popular y Windows usa la parte .3 hasta el día de hoy.

Linux tiene muchos archivos como .conf o .list o .d o .c que tienen significado, pero en realidad no son extensiones en el sentido 8.3. Por ejemplo, Apache mira /etc/apache2/sites-enabled/website.conf para su directiva de configuración. Si bien el sistema usa Tipos MIME y encabezados de contenido y qué no determinar si es un archivo de texto, Apache (por defecto) todavía no lo cargará sin que termine en .conf.

.c es otro excelente. Sí, es un archivo de texto, pero gcc depende de que main.c se convierta en main.o y finalmente en main (después del enlace). En ningún momento el sistema usa la extensión .c, .o o no para tener ningún significado en cuanto al contenido, pero las cosas después de. Tiene algún significado. Probablemente configuraría su SCM para ignorar main.o y main.

El punto es este: las extensiones no se usan de la misma manera que en Windows. El núcleo no ejecutará un archivo .txt porque elimina la parte .txt del nombre. También es muy feliz ejecutar un archivo .txt si se establece el permiso de ejecución. Dicho esto, tienen significado y todavía se usan en un "nivel de computadora" para muchas cosas.

— coteyr
fuente

1

Windows también no está ligado a la x.3estructura de nombres todas las extensiones más largas más, usted ha llegado hasta allí, así como .doxc, .torrent, .part, etc. Es sólo que muchos formatos de archivo y extensiones fueron ya definido de nuevo en el momento en nomenclatura 8.3 seguía siendo una cosa y luego los formatos en su mayoría simplemente adaptaron la convención de usar hasta 3 letras.

— Byte Commander

No veo cómo ".conf", ".c", etc., son "un significado diferente" del "sentido 8.3". El concepto de una extensión de archivo puede expresarse simplemente como "una convención para identificar el tipo de archivo basado en parte de su nombre". Ni siquiera DOS / Win3.1 requirió la extensión correcta (podría llamar a un documento de Word "STUPIDN.AME" y abrirlo con Ctrl-O en WinWord). Es solo que algunos sistemas (por ejemplo, hacer doble clic en Windows, gzipsu Makefile, etc.) pueden escribirse para usar esta convención para hacer suposiciones sobre la acción correcta que se debe realizar en cada archivo.

— IMSoP

@ByteCommander Eso es cierto, pero la extensión aún determina la aplicación utilizada. No estoy seguro de cómo editar la respuesta para reflejar eso.

— coteyr

1

@coteyr De nuevo, todo depende de lo que entendemos por "el sistema operativo". El Administrador de archivos seguramente buscará una clave de registro para "AME" y me dirá que "foo.txt" es un archivo de texto. Pero correr diren un símbolo del sistema no me dirá tal cosa; simplemente no le importará. La ejecución de archivos es ciertamente una excepción, en ambos sistemas operativos; si la pregunta se limitara a esas, la respuesta sería que DOS / Windows solo se preocupan por el nombre, y Unix / Linux solo se preocupa por el permiso de ejecución y los primeros bytes del archivo. Fuera de eso, siempre hay alguna aplicación que elige una convención a seguir.

— IMSoP

1

@coteyr Olvidó * .scr (protector de pantalla binario) en Windows 3.1 y versiones posteriores. Dicho esto, la extensión de archivo incluso en sistemas DOS / Windows, incluso para ejecutables, sigue siendo solo una conveniencia. Los detalles dependen mucho de dónde trazas la línea del "sistema operativo", pero siempre puedes cargar un binario en la memoria y saltar a ti mismo, haciendo el trabajo que normalmente se le pide al sistema operativo que haga. En MS-DOS, si mira a través de command.com, estoy bastante seguro de que hay una lista como EXE COM que puede editar de modo que busque otras extensiones si no se especifica ninguna (sin decir que sería una buena idea, te importa)

— un CVn