ls colors: ¿por qué algunas de mis fuentes son negras y otras verdes en ls output?

Subí algunos archivos de fuentes a AWS (ejecutando Amazon Linux) y los moví al /usr/share/fontsdirectorio usando un cpcomando en .ebextensions.

Cuando ingreso SSH desde mi Mac y uso ls -a, veo que algunos archivos tienen un color diferente: un conjunto de archivos de fuente es negro mientras que otros son verdes. Tengo curiosidad por saber qué causó esto, y si creará algún problema para mi código .

De otra respuesta en AskUbuntu encontré esta clave sobre cómo interpretar estos colores. No puedo entender por qué un .ttf sería ejecutable o por qué un conjunto de .ttfs sería reconocido y no otro.

Azul: Directorio

Verde: archivo de datos ejecutable o reconocido

Sky Blue: archivo vinculado

Amarillo con fondo negro: dispositivo

Rosa: archivo de imagen gráfica

Rojo: archivo de archivo

Todos estos archivos se descargaron a una Mac desde varios sitios de fuentes antes de cargarlos.

ls -lle dirá definitivamente si un archivo es ejecutable o no. No creo que haya ningún gran misterio aquí. Usted descargó archivos de varias fuentes, cada uno de los cuales podría tener diferentes bits de permiso establecidos por una razón u otra. ^* Si no le gusta ver algunos con colores y otros sin probar chmod -x *.ttf... los archivos de fuentes no deberían necesitar el conjunto de bits ejecutable.

* _{Como dice el comentario altamente votado de Matteo Italia, que debe preservarse, dice: Lo más probable es que se hayan copiado de un volumen FAT o NTFS, que no almacena el bit ejecutable, por lo que se montan de manera predeterminada para que todos los archivos tengan el bit ejecutable establecido .}

Parece que el lscomando que está ejecutando es un alias parals --color

hombre ls

--color [= CUANDO] colorea la salida; CUANDO puede ser 'siempre' (predeterminado si se omite), 'auto' o 'nunca'; más información a continuación

Puede verificarlo ejecutando el origen ls:

• Usando comillas:

  "ls" -a

• Usando la ruta completa (por ejemplo, si la lsubicación está en /bin/ls) y ver si muestra los colores o no:

  / bin / ls -a

Nota: la ejecución ls -lale mostrará los detalles de los archivos y podrá ver los detalles completos de cada archivo, lo que le permitirá verificar con la salida esperada dels --color

El color indica que el archivo está marcado como "ejecutable" *

Los bits de permiso ejecutables (uno para el usuario, uno para el grupo, uno para el otro) significa que si el nombre del archivo se pasa a una de las llamadas al sistema exec, el núcleo continuará e intentará ejecutarlo.

La convención es que solo los archivos que están destinados a ser ejecutados tienen el bit ejecutable establecido. Sin embargo, al mover / copiar archivos, especialmente en un entorno multiplataforma, es fácil ganar o perder inadvertidamente los bits ejecutables.

Es probable que los archivos almacenados en un sistema de archivos que no admite permisos de Unix (fat, ntfs, etc.) aparezcan en el sistema como ejecutables. Mover o copiar estos archivos a un sistema de archivos Unix utilizando una herramienta que conserva los permisos conservará esos bits ejecutables.

Por otro lado, el uso de herramientas para mover archivos que no pueden preservar los permisos o que se usan con la opción de preservar los permisos deseleccionados probablemente provoque que la copia no se marque como ejecutable aunque el original sí lo fuera.

Entonces, después de moverse por una variedad de plataformas utilizando una variedad de herramientas, los bits de permiso ejecutables pueden terminar en un estado bastante arbitrario.

* No estoy 100% seguro de cómo maneja ls el caso en el que se configuran algunos pero no todos los bits ejecutables.

Como dijeron las respuestas anteriores, el color es para indicar si los archivos se consideran ejecutables o no.

El permiso de "ejecución" (= bit) en Linux y la mayoría de los otros Unix tiene un significado para los archivos y otro para los directorios.

Para los directorios, si tiene permiso de ejecución, puede ver su contenido. Si no lo hace, no puede cd al directorio, ni puede enumerar archivos en él, incluso si tiene acceso de lectura y escritura al directorio.

Para los archivos normales (a diferencia de los archivos de dispositivo y otros tipos de archivos especiales de Unix), el bit de ejecución significa que si usa el nombre de archivo en la línea de comando, el O / S (o más precisamente: shell) intentará "ejecutar" o ejecutar el archivo como un comando Por el contrario, si no tiene permiso de ejecución en el archivo, no puede ejecutarlo desde la línea de comandos.

Entonces, si, por ejemplo, elimina el permiso x de todos los usuarios en el archivo / bin / cat (que es un comando de Unix), usted mismo o cualquier otra persona y cualquier programa que intente usar el comando "cat" fallará.

Esos son los comandos del sistema operativo, como "cat" y "grep", que normalmente tienen archivos ejecutables en los directorios / * / bin / - / bin, / usr / bin, / sbin, / usr / sbin, etc.

Y luego puede haber scripts interpretados sin compilar, que se escriben en algún lenguaje de programación, como Python o scripts de shell (básicamente, comandos que escribe como desde la línea de comandos cuando se envía al servidor).

Ahora, cuando configura bit de ejecución en el archivo de script (por ejemplo, el archivo foobar) e intenta ejecutarlo con su shell: "./foobar", el shell intenta analizar el archivo y encontrar el programa correcto para pasar el script a.

Esto lo hace el shell al intentar leer la primera línea del archivo y encontrar la notación "shebang" de qué programa se supone que debe ejecutarse.

Entonces, si su foobar era un archivo de texto con la primera línea como esta:

#!/usr/bin/python

Entonces shell intentaría ejecutar el comando: /usr/bin/python foobarbásicamente invocando al intérprete de Python y pasándole el nombre de su archivo foobar como un script de Python.

Si shell no encontrara esa primera línea en su archivo, entonces intentaría ejecutar foobar como si contuviera comandos de shell.

Si el archivo con bit ejecutable no contiene comandos de shell válidos, el shell simplemente se quejaría.

Entonces, esto es lo que sucedería si tuviera archivos TTF con bit de ejecución establecido e intentara ejecutarlo desde la línea de comandos:

$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$

Entonces, para las fuentes, probablemente sea más ordenado, si el bit exec no está configurado, pero realmente no cambia nada.

PD: solo alguna información extraña. Si elimina el bit de ejecución en algún comando o script, aún podría pasarse a cualquier otro programa como argumento. Si ese otro programa sabe cómo ejecutar su comando, su eliminación de bit exec realmente no importó. Por ejemplo, el script de Python foobar aún sería ejecutado por el intérprete de Python, si simplemente lo hiciera desde la línea de comandos:

$python foobar

en lugar de

$./foobar

Lo mismo con el ejemplo de los comandos del sistema, como "cat". Si elimina el bit exec de "cat", aún puede pasarlo a una nueva instancia de shell para su ejecución:

$sh -c 'cat myfile'

funcionará, incluso si ha eliminado bit exec de cat y

$cat myfile

no lo hace